SSOGEN / Learn / Free SAML Metadata Checker: Read Entity ID, Endpoints and Certificates
Free tool
Free SAML Metadata Checker: Read Entity ID, Endpoints and Certificates
SAML metadata is the XML file in which an identity provider or service provider states its entity ID, endpoints and certificates. Paste yours below to see those values and the problems that break federation.
Check a metadata file
Paste the XML, or open a file from your computer, then select Check metadata.
To see sample output first, load one of the two Acme samples. The identity provider sample is clean. The service provider sample is broken on purpose; the samples section below explains each fault.
The XML from your identity provider's metadata URL or the service provider's metadata page, starting with <EntityDescriptor. A metadata file can also be opened from your computer.
Private by design. The checks run in this page and nothing is sent anywhere. Metadata contains only public information (names, URLs, public certificates), but the file you paste may name internal hosts, so use a copy you are happy to look at on screen. This tool does not verify the metadata's own signature and does not fetch URLs.
The checks run in this page. Nothing is uploaded and no request is made. Metadata holds only public information, but the file you paste can name internal hosts, so use a copy that is safe to show on screen.
What SAML metadata holds
SAML metadata is the XML file that one side of a single sign-on connection gives to the other. It states who the party is (the entity ID), where to send messages (the endpoints) and which public certificates to trust.
Importing it is more reliable than typing those values by hand, provided the file is correct.
The checker below reads a metadata file in your browser and shows:
- the role, entity ID and expiry
- every endpoint with its binding and index
- each certificate with days left, key size and signature algorithm
It then flags the problems that most often break a federation.
Where to get a metadata file
There are two common sources, and both work for any SAML product.
-
A metadata URL. Many products publish metadata at an address. Open it in your browser and copy the XML source, or save the page as an
.xmlfile. An HTML page instead of XML means the address is wrong; the checker reports when the text is not well-formed XML.The SAML specification also describes publishing metadata at a well-known location derived from the entity ID (section 4.1, read 2026-10-08).
Products differ on whether they follow it, so use the address in the product’s own settings.
-
An export in the admin console. Look in the single sign-on settings for a button such as “Download metadata” or “Export SP metadata”. Download it from the application, not a generic page, so that it describes your connection.
In SSOGEN, a registered SAML application’s Integration tab shows SSOGEN’s own IdP metadata address, entity ID, single sign-on URL, NameID format and signing certificate.
Open the metadata address, save the XML and import it at the application. The steps are in register a SAML application.
A field-by-field guide
Each row names an element or attribute from the SAML 2.0 metadata specification (read 2026-10-08) and what must agree with the other side.
| Field | What it says | What must match on the other side |
|---|---|---|
entityID |
The party’s name. Required. The specification limits it to 1,024 characters. | The other side stores this string and compares it exactly: scheme, case, trailing slash. It is the Issuer on messages. |
validUntil |
When the metadata expires. | Nothing to match, but importers may refuse expired metadata. Re-import before this date. |
cacheDuration |
The longest a consumer should cache the metadata. | A consumer that refreshes automatically should re-read after this period. Keep it shorter than your certificate rollover window. |
SingleSignOnService (IdP) |
Where the IdP accepts sign-in requests, one element per binding. | The service provider sends requests to this address with a binding it supports. Redirect and POST are the usual two. |
AssertionConsumerService (SP) |
Where the SP accepts assertions. Carries a Binding, a Location and a required index. |
The IdP posts the assertion only to a registered address. The Location must be identical to what the IdP has on file, and index must be unique within the file. |
NameIDFormat |
The kind of identifier the party expects or sends: email address, persistent, unspecified. | The IdP sends this format and the SP maps it to an account. A mismatch gives “user not found” at the application. |
KeyDescriptor use="signing" |
A public certificate that verifies signatures made by this party. | The other side must hold this certificate, or it rejects signed messages. |
KeyDescriptor use="encryption" |
A public certificate for encrypting messages to this party. | Only needed if assertions are encrypted. The sender must encrypt to this certificate. |
Certificate rollover without an outage
The other side trusts exactly the certificates your metadata lists, so replacing one without coordination breaks sign-in. This checklist works with any pair of products.
- Issue the new certificate while the old one is still valid. Aim for at least 30 days of overlap, which is also when the checker starts warning.
- Publish both as separate
KeyDescriptor use="signing"elements. Consumers can then trust either one. - Tell the other side to import the metadata again, or wait for their scheduled refresh (see
cacheDuration). Confirm each connection imported it before you move on. - Switch signing to the new key. Assertions now carry its signature, and the other side already trusts it.
- Test a sign-in, then decode the response in the SAML tracer decoder and compare the certificate fingerprint with the one in the metadata.
- Remove the old certificate from the metadata once the last consumer has moved.
Step 3 is the one that causes outages when skipped: every sign-in fails signature verification the moment you switch keys.
The twelve checks
The tool runs these checks. Red items are faults that stop federation; amber items are risks to review.
| # | What it flags | Level | Why it matters |
|---|---|---|---|
| 1 | No entityID, or one with spaces |
Fault | The other side has nothing to identify you by. |
| 2 | entityID starting with http:// |
Risk | Only a name, but most deployments use https://. |
| 3 | validUntil in the past, or within 14 days |
Fault or risk | Importers may refuse expired metadata. |
| 4 | No IDPSSODescriptor or SPSSODescriptor |
Fault | Nothing to configure. |
| 5 | IdP with no SingleSignOnService, or SP with no AssertionConsumerService |
Fault | No place to send the request or the assertion. |
| 6 | Any endpoint on http:// |
Risk | Assertions should travel over HTTPS only. |
| 7 | Two AssertionConsumerService entries with the same index |
Fault | The index selects the endpoint, so it must be unique. |
| 8 | No HTTP-POST AssertionConsumerService |
Risk | Browser sign-in almost always uses HTTP-POST. |
| 9 | WantAssertionsSigned not true on an SP |
Risk | Asking for signed assertions is the safer choice. |
| 10 | Certificate expired, or under 30 days left | Fault or risk | Signatures made with it will fail once it lapses. |
| 11 | SHA-1 certificate signature, or RSA key under 2,048 bits | Risk or fault | Some systems refuse SHA-1; a short key is weak. |
| 12 | An IdP with no signing certificate, or an SP that signs requests but publishes no key | Fault | The other side cannot verify what you send. |
The tool also notes whether the metadata itself is signed. Unsigned metadata is normal, but fetch it over HTTPS from a source you trust: anyone who can change the file can swap the certificate.
The two Acme samples, and what each shows
The identity provider sample is https://sso.acme.example/saml/idp: one signing certificate, redirect and POST sign-in endpoints on HTTPS, a logout endpoint and an email NameID format. The checker flags nothing, which is what a healthy file looks like.
The service provider sample is https://erp.acme.example/saml/metadata, and each of its faults occurs in real files:
- An
http://assertion consumer URL. Plain HTTP would carry the assertion, so many identity providers refuse to register it. - Two ACS entries with
index="0". The second entry was copied and its index never changed, so the identity provider cannot tell which one to use. - A short-lived certificate and a near
validUntil. Both the file and the key expire soon, which produces an outage with no configuration change.
With those fixed, the file passes. Keep the unfixed sample as a regression test for your own export.
What SSOGEN does with metadata
SSOGEN reads metadata in both directions and reports specific errors.
SSOGEN as the identity provider. In the Add SAML application wizard, the Service provider metadata (optional) box reads the entity ID, the delivery address for the HTTP-POST binding and a signing certificate (not an encryption one).
It then shows “Read from metadata.xml. Check the values below — they are what SSOGEN will match exactly.”
A file it cannot use produces one of these messages:
- “That file is not valid XML.”
- “That XML has no EntityDescriptor, so it is not SAML metadata.”
- “That metadata describes an identity provider, not a service provider. Upload the application’s own metadata.”
- “That metadata has no entity ID or no assertion consumer service URL.”
The assertion consumer service URL must start with https://.
SSOGEN as the service provider. When you add a SAML identity provider, SSOGEN takes a metadata URL, a pasted file or an upload. A metadata URL must use HTTPS. SSOGEN refuses:
- a file with no sign-in endpoint: “That metadata publishes no HTTP-Redirect sign-in endpoint.”
- metadata with no usable certificate: “That metadata publishes no signing certificate, so assertions from it could not be verified.”
- any document that describes more than one entity
When the provider rolls its certificate, fetch the metadata URL again on the provider’s edit page. Save the revision, then validate, test and activate it.
Details are in add a SAML identity provider. The wider picture is on the SAML integration page.
What is SAML metadata?
What is an IdP metadata file?
IDPSSODescriptor. It lists the sign-in endpoints and the certificate that verifies the assertions the IdP signs.How do I find a SAML metadata URL?
Is it safe to paste metadata here?
Where to go next
- Values explained. ACS URL, entity ID and audience explains what each value means.
- A new file. Build a new file with the SAML metadata generator.
- Sign-in fails after the import. Decode the message with the SAML tracer and read the fields in a SAML assertion, annotated.
- One certificate. To read one certificate on its own, with fingerprints and chain order, use the certificate decoder.
Sources, all read 2026-10-09: SAML 2.0 metadata specification (OASIS).