1

I keep reading that in an X.509 certificate chain of trust that the "Issuer Name" in a certificate that has been signed by the Issuer must "match" the "Subject Name" of the Issuer's certificate. Exactly how is this match determined? Do all of the RDNs (Relative Distinguished Names) have to match between both the Subject Name and Issuer Name or is the match determined solely by the RDNs that are present in the Issuer certificate's Subject Name, or is some other match algorithm at work?

Improve this question
2
  • Does this answer your question? x.509 certificate-chain signatures verification
    – mentallurg
    Jul 4, 2020 at 19:45
  • No. What I'm trying to understand is the match detail underneath the "Issuer's (CA) name" to "Owner's (CA's) name" in the link you provided. It's the term "name" that needs more detail. Speaking precisely (which is sorely lacking when dealing with X.509 stuff), every certificate has a Subject Name and an Issuer Name. Each of these Names is composed of multiple Relative Distinguished Name ("RDN") fields (e.g., commonName, organizationName, etc.). My question is what constitutes a "match" between an issuing certificate's Subject Name and its signed certificate's Issuer Name?
    – Bill Vallance
    Jul 5, 2020 at 14:53

1 Answer 1

Reset to default
1

As per RFC 5280 §4.1.2.4 (and as specified in §7.1), binding is done by using case-insensitive match between Issuer distinguished name string of leaf certificate and Subject distinguished name string of a potential issuer.

Bear in mind that Key Match, Exact Match, Name Match techniques are used only to bind certificates and build as much chains as possible (build complete chain tree). It doesn't tell anything about trust/validity. When completed, tree is passed to validation routine which excludes invalid/non-suitable certificates and returns only single best chain. Full validation process is defined in RFC 5280 §6.

Certificate validation is a 3-step process:

  1. Tree building (from leaf to root)
  2. Tree validation (from root to leaf)
  3. Revocation checking (from leaf to root)

Name Match binding is used only during first process.

Improve this answer
10
  • I understand all of this. What I don't understand is what constitutes a "match" between an issuing certificate's Subject Name and its signed certificate's Issuer Name. Is the match made on a specific Relative Distinguished Name field (or fields) that are present in both the Subject Name and the Issuer Name or is some other match mechanism at work? I'm trying to understand this so that I can configure the policy settings in my OpenSSL config.cnf file correctly.
    – Bill Vallance
    Jul 5, 2020 at 14:57
  • I've added all necessary references that describe how name match is performed.
    – Crypt32
    Jul 5, 2020 at 15:00
  • I've just finished re-reading RFC 5280, Section 6. I have no clue how that answers my question, but I understand that there are processes much bigger at work than just matching Subject Name and Issuer Name. Can you give me the "dummies" answer to my question re: "Name Matching," or point me to a "dummies" reference that will explain it to me in layman's terms?
    – Bill Vallance
    Jul 5, 2020 at 15:27
  • Read §7.1 of referenced RFC. The link in my answer.
    – Crypt32
    Jul 5, 2020 at 15:28
  • Is this the answer? "Two distinguished names DN1 and DN2 match if they have the same number of RDNs, for each RDN in DN1 there is a matching RDN in DN2, and the matching RDNs appear in the same order in both DNs. A distinguished name DN1 is within the subtree defined by the distinguished name DN2 if DN1 contains at least as many RDNs as DN2, and DN1 and DN2 are a match when trailing RDNs in DN1 are ignored."
    – Bill Vallance
    Jul 5, 2020 at 15:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.