3

I work in an organization which is employing what I believe to be a non-standard and problematic PKI system for internally used certificates.

They issue multiple root certificates and intermediate certificates with the same subject name with different validity periods. The public keys are also different.

When I look up an Issuer Name it gives a subject which could match multiple different certs. Some underlying implementation must be determining which cert is the actual issuer.

OpenSSL hashes certificates according to their subject and installs them in a particular place. It does allow duplicate hashes and creates multiple sym links.

I think we have faced problems in dealing with these multiple root and intermediate certs on servers. Sometimes deleting an unused expiring cert has caused TLS to fail. I don't know if this because of this re-using of subject lines and a problem with OpenSSL getting some order messed up. Or it is some other issue and this duplicate subjects for root and intermediate certs is normal.

I would appreciate any feedback on this. I searched the RFC document and saw this but found it confusing because it refers to a subject entity which I assume is the real world entity. So I believe this says you can issue multiple certs for the same real world entity with the same subject. Which is fine. But my question is around intermediate issuer certs.

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.

Improve this question
7
  • Do these certificates with different subjects have the same public key or a different one? If they are the same then it should be not really a problem as long as the valid ones are included with the certificate chain.
    – Steffen Ullrich
    Apr 5, 2019 at 15:15
  • @SteffenUllrich Thanks. I didn't think to check that before. They are different public keys. Can you explain why this might be a problem? They do present the full chain. I experiment with clearing certs and using update-ca-certificates on ubuntu to selectively add certs and the whole thing is very difficult to understand. I want to present something to them.
    – Amala
    Apr 5, 2019 at 15:30
  • I am now seeing this related question: security.stackexchange.com/questions/159868/… Which suggests that a certificate with a differing validity with the same public key is ok.
    – Amala
    Apr 5, 2019 at 15:32
  • 1
    It is the combination of Subject Name and Public Key which makes a certificate unique. If either of those change, it is a completely different certificate as far as verification is concerned. It can be either or both. It just confuses us humans when only the Public Key changes and the Subject Name remains the same :-)
    – garethTheRed
    Apr 5, 2019 at 17:33
  • @garethTheRed Thanks. That is what we were discussing as well. It is more of a problem and time sink for all the operators trying to rotate keys and such. The browsers aren't confused like the humans.
    – Amala
    Apr 5, 2019 at 20:17

1 Answer 1

Reset to default
5

It is the combination of Subject Name and Public Key which makes a certificate unique. If either of those change, it is a completely different certificate as far as verification is concerned. It can be either or both.

It just confuses us humans when only the Public Key changes while the Subject Name remains the same.

Therefore, in your case, the names are the same; but the keys aren't. That is, they are two different certificates that belong to the same CA.

To aid the comparison process, many CAs add a Subject Key Identifier (SKI) and Authority Key Identifier (AKI) extensions to certificates they sign. The values in these extensions are derived from the Public Key (of the Subject for SKI and Issuer for AKI); usually in the form of a SHA-1 hash. With these in place, it's now a matter of comparing a relatively short hash rather than the much longer public key.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .