CA with multiple certificates

[boaks]

version 4.2.1

If the cafile contains multiple certificates for a shared DN (see discussion leshan CA update ), libcoap/openssl seems to chose the last certificate among the certificates with the same DN within that cafile. Is there any option to support CAs with multiple certificates for a CA update according RFC 6489 - Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)?

[mrdeep1]

As per https://tools.ietf.org/html/rfc6489#section-2, there is

      2. Generate a certificate request with this key pair and pass the
         request to the CA that issued the CURRENT CA certificate.  This
         request MUST include the same SIA extension that is present in
         the CURRENT CA certificate.  This request, when satisfied, will
         result in the publication of the NEW CA certificate.  This
         (NEW) CA certificate will contain a subject name selected by
         the issuer, which MUST be distinct from the subject name used
         in the CURRENT CA certificate.  

where the new CA MUST have a different subject name, so I am struggling with there being multiple CAs with the same DN.

I would expect the -C cafile option cafile to contain both the current and new CAs (and any necessary intermediate CAs) if there is to be this rollover.

Or am I missing something here?

[boaks]

Thanks! That is clear - and strange at the same time :-).

I was reading other sources about CA updates last week.
My bad, I didn't really read that RFC.

About the possibilities of multiple certificates and same DN

RFC5280 4.1.2.6. Subject

Where it is non-empty, the subject field MUST contain an X.500
distinguished name (DN). The DN MUST be unique for each subject
entity certified by the one CA as defined by the issuer field. A CA
MAY issue more than one certificate with the same DN to the same
subject entity.

The "other source" recommended not to changed the DN of the CA on update.
I tried to find it again, but in vain ... (my browse history is too huge)
I'm not sure, what will be the right way to do it. I got just aware, if one plans to update the CA certificates without changing the DN, then client need to obviously support that. Or that approach must not be used.
We will see.

[boaks]

Changing a CA’s Subject DN; Part I: Don’t Do That

Finally, I found it again.

But, as written above, updating the x509 CA may be done different, it's not my fight to do it in that way.

[mrdeep1]

RFC5280 4.1.2.6. Subject

Where it is non-empty, the subject field MUST contain an X.500
distinguished name (DN). The DN MUST be unique for each subject
entity certified by the one CA as defined by the issuer field. A CA
MAY issue more than one certificate with the same DN to the same
subject entity.

There is nothing wrong with a CA refreshing a subject entity (i.e. changing the validity dates) certificate and keeping the same DN - this could be for an intermediate CA as well.

Having multiple "trusted" CAs with the same DN does worry me - potential for trouble if a bad impersonating CA is inadvertently added to the trusted list. I don't know enough about PKI as to what happens when you simply refresh the CA to update its validity dates, keeping the same DN (and private key). Hence why RFC6489 and associated RFCs came into being I guess.

[boaks]

potential for trouble if a bad impersonating CA is inadvertently added to the trusted list.

AFAIK, only the DN may be "impersonated", if the "true" CA keeps his private key private, everything should be secure.

To support multiple certificates with the same DN is mainly to check, which of the certificate of the DN is really used to sign the "next" certificate and is still valid. For Californium I currently adapt this.

I still wondering, what the "really recommended" process will be. Finally, it's left to the "system-builder", what they want to do. And my feeling is, it's anyway important for them to test all involved implementations for the possibilities.

[mrdeep1]

libcoap is very dependent on what the underlying TLS library is doing and what criteria the TLS library uses for deciding whether to send a Certificate Request and how things are handled when a Certificate (or no Certificate) is returned. Likewise the TLS library (client) implementations do not always do the same thing when asked for a Certificate Request (as I discovered when working on #561 ).

I agree that if possible, all eventualities need to be covered (providing security is not compromised), but libcoap is restricted by the TLS support capabilities and what the TLS library external APIs are available to control things.

[mrdeep1]

For OpenSSL SSL_CTX_load_verify_locations there is the warning

WARNINGS
If several CA certificates matching the name, key identifier, and serial number condition are available,
only the first one will be examined. This may lead to unexpected results if the same CA certificate is
available with different expiration dates. If a "certificate expired" verification error occurs, no other
certificate will be searched. Make sure to not have expired certificates mixed with valid ones.