Certificate Test Scenarios

Generate deliberately bad client certificates and see how registration fails

Generate a certificate
One of them must equal the iss claim of the software statement. At most 10.
Send this body as POST /api/cert/generate with Content-Type: application/json. It follows the form as you edit it.
Scenario What is wrong Registration result Applies
Valid certificate
valid 		A certificate issued by the server's own intermediate CA with a URI subject alternative name, a CRL distribution point, and a full chain. Every check in the referenced clause passes. Accepted IG §3.2.3 DCR §4.2
Expired certificate
expired 		The certificate's NotAfter date is one day in the past. Path validation fails on certificate validity, so no trusted chain can be built and the request is denied before the software statement claims are examined. Rejected
unapproved_software_statement
 IG §7.1.6 DCR §4.2
Certificate not yet valid
not-yet-valid 		The certificate's NotBefore date is one day in the future. RFC 5280 path validation checks the whole validity period, not only expiry, so the chain is rejected the same way an expired one is. Rejected
unapproved_software_statement
 DCR §4.2 IG §7.1.6
Untrusted root
untrusted-root 		The chain is complete and well formed but ends at a root that no community on this server trusts, so no chain to a trusted anchor exists. Rejected
unapproved_software_statement
 DCR §4.2 IG §7.1.6
Revoked certificate
revoked 		A valid certificate whose serial number is added to the intermediate CA's CRL before it is returned. Revocation status checking during path validation finds the entry. Rejected
unapproved_software_statement
 IG §7.1.6 DCR §4.2
No CRL distribution point
no-cdp 		The certificate has no CRL distribution point extension, so it does not tell a validator where its CRL is. The referenced clause requires revocation status checking but does not say what to do when the certificate points to no CRL. This server checks revocation only through CRL distribution points, treats the missing extension as nothing to check, and accepts the registration. Accepted DCR §4.2
Unreachable CRL distribution point
dead-cdp 		The CRL distribution point points at a URL that returns 404, so revocation status cannot be determined. This server treats unknown status as a failed path validation and denies the request. Rejected
unapproved_software_statement
 DCR §4.2
No subject alternative name
missing-san 		The certificate has no subject alternative name, so no URI can match the iss claim of the software statement. This server fails the iss check while validating the JWT, before trust evaluation, which is why the error code is the signature one rather than the trust one. Rejected
invalid_software_statement
 IG §3.1 DCR §4.3
Chain without the intermediate
missing-intermediate 		The PKCS#12 bundle omits the intermediate certificate. The x5c header may carry only the leaf, and the server may complete the chain from its own store or AIA. This server already trusts that intermediate from its CertStore, so registration succeeds. Accepted DCR §4.2 IG §7.1.3
Conformance text
IG §3.2.3 HL7 FAST Security IG STU2, 3.2.3 Request Body
The Authorization Server SHALL validate the registration request as per Section 4 of UDAP Dynamic Client Registration. This includes validation of the JWT payload and signature, validation of the X.509 certificate chain, and validation of the requested application registration parameters.
DCR §4.2 UDAP Dynamic Client Registration STU1, incorporated by FAST IG §3.2.3, Section 4.2
The Authorization Server attempts to construct a valid certificate chain from the Client’s certificate (cert1) to an anchor certificate trusted by the Authorization Server using conventional X.509 chain building techniques and path validation, including certificate validity and revocation status checking. [...] If a trusted chain cannot be built and validated by the Authorization Server, the request is denied.
IG §7.1.6 HL7 FAST Security IG STU2, 7.1.6 JWT validation
[...] the requirement that the JWT consumer validate that it trusts the corresponding JWT’s producer’s X.509 certificate by constructing a valid certificate chain from the JWT producer’s certificate to an anchor trusted by the JWT consumer, and by verifying that the certificates in the chain have not expired or been revoked.
IG §3.1 HL7 FAST Security IG STU2, 3.1 Software Statement, iss claim
Issuer of the JWT -- unique identifying client URI. This SHALL match the value of a uniformResourceIdentifier entry in the Subject Alternative Name extension of the client's certificate included in the x5c JWT header and SHALL uniquely identify a single client app operator and application over time.
DCR §4.3 UDAP Dynamic Client Registration STU1, incorporated by FAST IG §3.2.3, Section 4.3
The iss value MUST match a uriName entry in the Subject Alternative Names extension of the Client’s certificate.
DCR §4.2 UDAP Dynamic Client Registration STU1, incorporated by FAST IG §3.2.3, Section 4.2
The Client MAY submit a complete certificate chain in its request. The Authorization Server MAY use additional certificates not included by the Client to construct a chain (e.g. from its own certificate cache or discovered via the X.509 AIA mechanism). Authorization Servers SHOULD support the X.509 AIA mechanism for chain building.
IG §7.1.3 HL7 FAST Security IG STU2, 7.1.3 JWT headers, x5c
An array of one or more strings containing the X.509 certificate or certificate chain, where the leaf certificate corresponds to the key used to digitally sign the JWT. [...] with the leaf certificate appearing as the first (or only) element of the array.
DCR §5.2 UDAP Dynamic Client Registration STU1, incorporated by FAST IG §3.2.3, Section 5.2
Denials related to trust validation SHOULD use the “unapproved_software_statement” code. Denials related to invalid signatures SHOULD use the “invalid_software_statement” code.