Verifying Certificate Chain - Am I doing this correctly?

[Abigail Watson]

Good morning!
So, got a question about verifying certificate chains (as part of the UDAP Dynamic Client Registration workflow).  I'm running up on a blocking issue, and am currently trying to debug both syntax/grammar as well as correct order of operations on the certificates and keys themselves.   

Original write up of the issue was filed to the node-forge project for verification of correct syntax, which can be found here:  https://github.com/digitalbazaar/forge/issues/955

Essential code snippet provided here:
 

So, here's my question for the UDAP group:  could you help confirm that we're doing the correct order of operations on the correct certificates?

It's the x5c certificate in the header of the incoming software_request that's the 'certificate chain', correct?  And we're suppose to be validating it against EMRDirectTestCA.crt (aka Test Tool Anchor Certificate), correct?  Or are we suppose to be validating against the self-signed server certificate?  

Any help would be much appreciated!  Thanks!
Abigail Watson

Abigail Watson
Principal FHIR Software Engineer
Open Health Services, MITRE
awa...@mitre.org

[UDAP]

Hi Abigail,

I think you may want to share how you have defined verifyCertificateChain function or provide the documentation for that function, so we can provide more specific feedback?

The process is similar to validating the assertions in section 6 of UDAP Client Authorization Grants using JSON Web Tokens, except that for UDAP DCR you only need to validate the signature and confirm the certificate is trusted, and usually that also means making sure the certificate has not expired or been revoked, nor has its issuer. 

The server's own certificate is not in scope here - that is for validation by counter parties as per UDAP Server Metadata. You should be validating against your set of trusted CA certificates for this purpose (which needs to include the EMRDirectTestCA if you are using the UDAP Test Tool).

I'm assuming you're adding back the BEGIN and END because your library only understands PEM.

I don't see that the decoded signed software statement is checked to see that the JWT is still valid and is for the correct aud (or additional validation as per local policy/TBD).

Climbing the certificate chain to validate that the root or some intermediate cert is trusted is a separate step. The x5c[0] cert is the first link in the certificate chain; a complete certificate chain needs to be constructed from x5c[0] to an anchor in your caStore.

For more information about certificate chaining, see section 3.2 of RFC 5280. The chain is built sufficiently to validate trust with some intermediate issuer or the root certificate. The process is likely well established in PKI libraries you'll encounter, but if you think more details summarizing relevant aspects of the referenced RFCs would be helpful, let us know.

[Abigail Watson]

Mmmm....  I'm sort of following along.  Have read RFC 5280, and am trying to following the instructions.  When I inspect the certificates involved, here is what I'm finding:  

EMRDirectTestCA

subject:   Certification Authority (certs.emrdirect.com)
issuer:     Certification Authority (certs.emrdirect.com)

Incoming x5c Header Cert
subject:   UDAP Test Certificate NOT FOR USE WITH PHI
issuer:     UDAP Test Certificate NOT FOR USE WITH PHI

I'd understand how to construct a chain if the cert in the incoming x5c header had an issuer of Certification Authority (certs.emrdirect.com), but it doesn't.  It looks like the x5c header is self-signed, and doesn't chain to anything.  

[UDAP]

Hi Abigail,

It appears you are not capturing the full distinguished name of the issuer correctly. You'll want to look at properties of the certificate itself to find the full issuer distinguished name, and its AIA details in order to find the certificate of the issuing intermediate CA.

For example, if you have OpenSSL, you could view this information with: $openssl x509 -in cert.pem -noout -text

The additional information in the certificate is discussed in RFC 5280 section 4.2.2.1 Authority Information Access.

[Tom Loomis]

Abigail:

When we did this in node we struggled a bit with this part as well.  In the end we ended up manually building the chain as an array by following the AIA (Authority Information Access) from the cert based in.  Then we used that chain as the second argument of the pki.verifyCertificateChain method in node forge.   We never found a library that built the chain for us which is why we did it manually.   We will probably be refactoring a bit over  the next few weeks.

Tom

[Abigail Watson]

Ah!  Found the correct issuer information in the certificate!  And the extensions array with the authorityInfoAccess url for the intermediary certificate(s).  Yup, agreed that just going to need to fetch each of these algorithmically.  Now trying to decode data received from an HTTP.get() and content type application/x-x509-ca-cert.  It's ostensibly a DER file, and I can verify that the .crt file it downloads opens in a validator tool.  Doing it algorithmically has got me going in circles with btoa/atob, Buffers, utf8/ascii/binary, ans1, Forge certificates, etc.  Something in the HTTP.get() isn't behaving the same as the download link which uses a file handler, and it's mangling the encoding.  :sigh:

Thanks for the help and pointers.  I'm getting through it.  Slowly.  
Abigail    

[Abigail Watson]

Thanks for the help, everybody.  Got it all passing green.