DCDT 2015 trust anchor

81 views
Skip to first unread message

jch...@athenahealth.com

unread,
Feb 28, 2017, 2:39:32 PM2/28/17
to Direct Certificate Discovery Tool
Hi! I clicked on the link to download the trust anchor under step 1 of "Discover DCDT certificates". Chrome said the site cannot be reached (ERR_CONNECTION_REFUSED).

I tried removing the :8080 port number from the URL, and this did result in downloading a certificate that seems to be intended to be the trust anchor (its subject = dcdt31prod.sitenv.org_ca_root), however it appears it is not actually the issuer of e.g. the certificate for case D1. The anchor I downloaded has a subject key identifier field of "d0 04 29 53 f4 b3 4e 91 db 75 52 df f5 0e 52 9c 3c ae fb 97 27 f8 73 7d 19 a3 06 28 f5 bc d0 92" whereas the D1 certificate (subject = D1_valA) has an authority key identifier field of "7d 30 35 00 8a e6 03 ef 7a 20 5d 12 f7 a4 7c 57 5f 90 88 2c". Since these don't match our cryptography library rejects the anchor.

Where is the correct anchor?

Thanks!
Jason

sandeep...@gmail.com

unread,
Feb 28, 2017, 3:01:00 PM2/28/17
to Direct Certificate Discovery Tool, jch...@athenahealth.com

http://dcdt31prod.sitenv.org:8080/dcdt/discovery

You can download the trust anchor from the above link.

Thanks,

Sandeep

jch...@athenahealth.com

unread,
Feb 28, 2017, 3:06:05 PM2/28/17
to Direct Certificate Discovery Tool, jch...@athenahealth.com, sandeep...@gmail.com
No, that is the same link that is available from the DCDT page. As I said, when I open that URL, the connection is refused in both Chrom and Internet Explorer:

"dcdt31prod.sitenv.org refused to connect."

Sandeep Savarala

unread,
Feb 28, 2017, 3:13:14 PM2/28/17
to directt...@googlegroups.com, jch...@athenahealth.com
Inline image 1

I was able to open the link in both Chrome and IE. I am also attaching the trust anchor for you.

Hope this helps.

On Tue, Feb 28, 2017 at 3:06 PM, <jch...@athenahealth.com> wrote:
No, that is the same link that is available from the DCDT page. As I said, when I open that URL, the connection is refused in both Chrom and Internet Explorer:

"dcdt31prod.sitenv.org refused to connect."

--
You received this message because you are subscribed to a topic in the Google Groups "Direct Certificate Discovery Tool" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/directtesttool/WHcZFA0zxw4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to directtesttool+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/directtesttool.
To view this discussion on the web visit https://groups.google.com/d/msgid/directtesttool/b0c2fcee-c291-431c-b03e-52945e7ed547%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Sandeep Savarala
Graduate Student
Johns Hopkins University Homewood Campus
dcdt31prod.sitenv.org_ca_root.der

jch...@athenahealth.com

unread,
Feb 28, 2017, 3:19:40 PM2/28/17
to Direct Certificate Discovery Tool, jch...@athenahealth.com, sandeep...@gmail.com
Thanks very much! Unfortunately this is the same anchor I was able to download from port 80, whose subject key identifier does not match the authority key of the D1 certificate. Because these do not match, our system is rejecting the issuer and will not allow encrypting with the certificate. Do you have any suggestions?

SIT...@hhs.gov

unread,
Mar 8, 2017, 8:59:52 AM3/8/17
to Direct Certificate Discovery Tool, jch...@athenahealth.com, sandeep...@gmail.com
Hello,

The workaround is to use this URL: http://dcdt31prod.sitenv.org/dcdt/discovery/anchor  (No SSL)

If there is an issue with the anchor, please let us know.  

Thank you


Srini Adhinarayanan

unread,
Mar 8, 2017, 9:32:38 AM3/8/17
to directt...@googlegroups.com, sandeep...@gmail.com

Sandeep, you did pass the downloaded cert to them in the earlier mail, but they seem to be complaining about the “content” of the cert?

In which case, if it is valid, it would be a fix. But this has been around for some time, maybe it is a user error.

--
You received this message because you are subscribed to the Google Groups "Direct Certificate Discovery Tool" group.
To unsubscribe from this group and stop receiving emails from it, send an email to directtesttoo...@googlegroups.com.


For more options, visit https://groups.google.com/d/optout.



Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more Click Here.

jch...@athenahealth.com

unread,
Mar 8, 2017, 10:47:27 AM3/8/17
to Direct Certificate Discovery Tool, sandeep...@gmail.com
Thanks, but that is once again the same anchor that I already received. Again, the problem is that the anchor has a Subject Key Identifier extension field that does not match the Authority Key Identifier field in the discovered certificates. The cryptography library we are using (and cannot modify) rejects the certificate as untrusted if the anchor has a Subject Key Identifier field present, and the issued certificate has an Authority Key Identifier present, and they don't match exactly. This is a pretty standard step for ensuring that the anchor did in fact issue the discovered certificate, and we have been happily exchanging Direct messages with other HISPs using this library for years now.

The relevant sections of RFC5280 are 4.2.1.1 and 4.2.1.2. In particular from 4.2.1.2:

In conforming CA certificates, the value of the
subject key identifier MUST be the value placed in the key identifier
field of the authority key identifier extension (Section 4.2.1.1) of
certificates issued by the subject of this certificate.


OS - ONC SI&T Team

unread,
Mar 8, 2017, 11:33:21 AM3/8/17
to directt...@googlegroups.com, sandeep...@gmail.com

We’ll look into the issue.

 

Thank you

 

From: directt...@googlegroups.com [mailto:directt...@googlegroups.com] On Behalf Of jch...@athenahealth.com
Sent: Wednesday, March 08, 2017 10:47 AM
To: Direct Certificate Discovery Tool
Cc: sandeep...@gmail.com
Subject: Re: [DCDT Google Group] Re: DCDT 2015 trust anchor

 

Thanks, but that is once again the same anchor that I already received. Again, the problem is that the anchor has a Subject Key Identifier extension field that does not match the Authority Key Identifier field in the discovered certificates. The cryptography library we are using (and cannot modify) rejects the certificate as untrusted if the anchor has a Subject Key Identifier field present, and the issued certificate has an Authority Key Identifier present, and they don't match exactly. This is a pretty standard step for ensuring that the anchor did in fact issue the discovered certificate, and we have been happily exchanging Direct messages with other HISPs using this library for years now.

--
You received this message because you are subscribed to a topic in the Google Groups "Direct Certificate Discovery Tool" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/directtesttool/WHcZFA0zxw4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to directtesttoo...@googlegroups.com.

srini

unread,
Mar 8, 2017, 11:44:01 AM3/8/17
to directt...@googlegroups.com, sandeep...@gmail.com

Thank you for your response, just wanted to add that on digging deeper this field though a MUST match - is not part of the validation but only to assist in path building - as exemplified by the last line following to the excerpt from the RFC 4.2.1.2:.. viz..

To facilitate certification path construction, this extension MUST appear in all conforming CA certificates, that is, all certificates including the basic constraints extension (Section 4.2.1.9) where the value of cA is TRUE. In conforming CA certificates, the value of the subject key identifier MUST be the value placed in the key identifier field of the authority key identifier extension (Section 4.2.1.1) of certificates issued by the subject of this certificate. Applications are not required to verify that key identifiers match when performing certification path validation.

There are some discussions to this point in the internet, for instance here

Having said that we shall address this issue and follow up - please let us know if the above information adds any further value.

Thanks
srini

On Wed, Mar 8, 2017 at 11:33 AM, OS - ONC SI&T Team <SIT...@hhs.gov> wrote:

We’ll look into the issue.

 

Thank you

 

From: directtesttool@googlegroups.com [mailto:directtesttool@googlegroups.com] On Behalf Of jch...@athenahealth.com
Sent: Wednesday, March 08, 2017 10:47 AM
To: Direct Certificate Discovery Tool
Cc: sandeep...@gmail.com
Subject: Re: [DCDT Google Group] Re: DCDT 2015 trust anchor

 

Thanks, but that is once again the same anchor that I already received. Again, the problem is that the anchor has a Subject Key Identifier extension field that does not match the Authority Key Identifier field in the discovered certificates. The cryptography library we are using (and cannot modify) rejects the certificate as untrusted if the anchor has a Subject Key Identifier field present, and the issued certificate has an Authority Key Identifier present, and they don't match exactly. This is a pretty standard step for ensuring that the anchor did in fact issue the discovered certificate, and we have been happily exchanging Direct messages with other HISPs using this library for years now.

 

The relevant sections of RFC5280 are 4.2.1.1 and 4.2.1.2. In particular from 4.2.1.2:

 

In conforming CA certificates, the value of the
subject key identifier MUST be the value placed in the key identifier
field of the authority key identifier extension (Section 4.2.1.1) of
certificates issued by the subject of this certificate.

 

 

--
You received this message because you are subscribed to a topic in the Google Groups "Direct Certificate Discovery Tool" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/directtesttool/WHcZFA0zxw4/unsubscribe.

To unsubscribe from this group and all its topics, send an email to directtesttool+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Direct Certificate Discovery Tool" group.
To unsubscribe from this group and stop receiving emails from it, send an email to directtesttool+unsubscribe@googlegroups.com.

jch...@athenahealth.com

unread,
Mar 8, 2017, 12:05:54 PM3/8/17
to Direct Certificate Discovery Tool, sandeep...@gmail.com
Right, applications are not required to do so. They are also not prohibited from doing so. The language is unambiguous that the CA must place a matching value in its issued certificates, whereas it is ambiguous what consumers should do with it.


On Wednesday, March 8, 2017 at 11:44:01 AM UTC-5, Srinivasan Adhinarayanan wrote:

Thank you for your response, just wanted to add that on digging deeper this field though a MUST match - is not part of the validation but only to assist in path building - as exemplified by the last line following to the excerpt from the RFC 4.2.1.2:.. viz..

To facilitate certification path construction, this extension MUST appear in all conforming CA certificates, that is, all certificates including the basic constraints extension (Section 4.2.1.9) where the value of cA is TRUE. In conforming CA certificates, the value of the subject key identifier MUST be the value placed in the key identifier field of the authority key identifier extension (Section 4.2.1.1) of certificates issued by the subject of this certificate. Applications are not required to verify that key identifiers match when performing certification path validation.

There are some discussions to this point in the internet, for instance here

Having said that we shall address this issue and follow up - please let us know if the above information adds any further value.

Thanks
srini
On Wed, Mar 8, 2017 at 11:33 AM, OS - ONC SI&T Team <SIT...@hhs.gov> wrote:

We’ll look into the issue.

 

Thank you

 

From: directt...@googlegroups.com [mailto:directt...@googlegroups.com] On Behalf Of jch...@athenahealth.com
Sent: Wednesday, March 08, 2017 10:47 AM
To: Direct Certificate Discovery Tool
Cc: sandeep...@gmail.com
Subject: Re: [DCDT Google Group] Re: DCDT 2015 trust anchor

 

Thanks, but that is once again the same anchor that I already received. Again, the problem is that the anchor has a Subject Key Identifier extension field that does not match the Authority Key Identifier field in the discovered certificates. The cryptography library we are using (and cannot modify) rejects the certificate as untrusted if the anchor has a Subject Key Identifier field present, and the issued certificate has an Authority Key Identifier present, and they don't match exactly. This is a pretty standard step for ensuring that the anchor did in fact issue the discovered certificate, and we have been happily exchanging Direct messages with other HISPs using this library for years now.

 

The relevant sections of RFC5280 are 4.2.1.1 and 4.2.1.2. In particular from 4.2.1.2:

 

In conforming CA certificates, the value of the
subject key identifier MUST be the value placed in the key identifier
field of the authority key identifier extension (Section 4.2.1.1) of
certificates issued by the subject of this certificate.

 

 

--
You received this message because you are subscribed to a topic in the Google Groups "Direct Certificate Discovery Tool" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/directtesttool/WHcZFA0zxw4/unsubscribe.

To unsubscribe from this group and all its topics, send an email to directtestto...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Direct Certificate Discovery Tool" group.
To unsubscribe from this group and stop receiving emails from it, send an email to directtesttoo...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages