SimpleSAMLphp can sign the metadata it generates and can validate signed metadata from other entities. That makes certificates part of the federation trust model. A valid signature only says that a known key signed the document. Operators still need to decide which keys are trusted, how metadata is refreshed, and what happens when a certificate expires or changes.
Signing and verification are separate jobs
SimpleSAMLphp's advanced feature documentation describes enabling metadata signing and configuring a private key and certificate. Remote metadata sources can specify the certificate files used to verify a signature. The signing key protects the metadata an identity provider or service provider publishes. The verification key protects what a consumer accepts.
Record both sides. A local configuration that signs outbound metadata does not automatically validate inbound metadata. A remote entity that validates the local metadata may require a specific algorithm or certificate set.
Keep private keys out of shared metadata
The certificate is public and belongs in metadata. The private key must remain restricted to the service that signs. File permissions, backups, and deployment artifacts should not expose it. Use a dedicated key for each entity and environment.
The SimpleSAMLphp maintenance documentation warns that the certificate included in the distribution is not suitable when it has been exposed. Replace sample credentials before production use. The same principle applies to copied federation keys and private keys included in container images.
What the ZoomEye observation shows
The count-only queries used sub_type=all, page 1, and page size 1. app="SimpleSAMLphp" returned 0, title="SimpleSAMLphp" returned 963, and http.body="SimpleSAMLphp" returned 4,323.
The zero application result is a successful measurement, not an error. The title and body counts show product references but do not prove that a federation endpoint, metadata publisher, or administrative interface is exposed.
Use the observations to reconcile public references with owned identity providers and certificate inventory. Do not fetch sensitive metadata or attempt authentication against unknown services.
Plan certificate rollover
Add the new verification certificate alongside the old one before switching the signing key. Publish metadata, wait for consumers to refresh, then remove the old certificate after the documented overlap. Test both old and new signatures during the transition.
Confirm how metadata is cached and whether a refresh failure leaves the last good copy in place. A stale cache can turn a planned rollover into an outage. It can also preserve trust in a revoked key for longer than intended.
Validate the federation path
Test a signed metadata document, a malformed signature, an expired certificate, and an unknown issuer. Confirm that the service rejects each case for the expected reason. Review the trust anchors for remote metadata and remove entities that no longer belong to the federation.
Monitor certificate expiry, metadata refresh failures, signature validation errors, and changes to the trusted certificate set. The security decision is not merely whether metadata is signed. It is which keys are accepted, how those keys rotate, and whether the service fails safely when the evidence is wrong.