1

For my studies, I'd like to dive a bit deeper into PKI and X.509. Talking about certificates, one always gets the following sentence:

"Digital certificates map public keys to entities"

This means, trusting any CA in the corresponding certificate chain and knowing the entity, I can trust the public key and thus establish a secure channel.

But how do I know the entity. For instance, when I want to check out some (TLS-enabled) web page, I just know the Domain Name. And there's no real correlation between the URL and the entity, or am I wrong here. I always thought, the subject name indicates a correlation here, but as Peter Gutmann states it:

Ns don't really work - there's no clear idea of what they should look like, most users don't know about (and don't want to know about) X.500 and its naming conventions, and as a consequence of this the DN can end up containing just about anything.

Imagine a situation where an attacker is able to modify a DNS request and send me a forged DNS response with a bad IP in it. Imagine further, the attacker owns a certificate issued by a CA I trust? How would I be able to detect the evildoer here?

Improve this question

3 Answers 3

Reset to default
4

Your question doesn't seem to be the reason for Subject Name, which is to identify the subject, but rather whether it works.

Gutmann writes colorfully and at some length on things that actually don't matter most of the time, although when they do it's very useful to know about them. Yes, the full X.500 naming scheme specified to be used in X.509 certificates in general is a monster. (Committee designs are traditionally depicted as camels, although in this case octopus seems appropriate.)

However, SSL/TLS certificates and particularly web server certificates -- which is the only kind most people encounter and the only specific case in your question -- avoid the issue by really using only the CommonName attribute in Subject(name) to contain a 'fully-qualified' domain (DNS) name aka FQDN, or possibly (but rarely) an IP address; or nowadays usually the SubjectAlternativeName extension to contain FQDN(s) and possibly IP address(es). Although in actual operation (especially at its current worldwide scale) DNS isn't perfect either, most people can understand it easily enough, and certainly the domainname in an http:// or https:// URL is easy enough to see.

A legitimate CA should issue a certificate for a given domainname only to the 'owner' of that domain, although exactly what counts as ownership varies a little. You can visit each CA site and look at their application/validation rules and processes, or see CA/Browser Forum under Baseline Requirements which sets the (minimum) standards for CAs to be included in the truststores of most browsers and OSes (at least on consumer devices), and thus the ones most users end up trusting.

Thus, if the CAs do their job and attacker M can't either trick or force a trusted CA into wrongly issuing him a cert for domain D -- which has happened in a small number of cases, but not so many as to be a big problem -- M can't impersonate the website of domain D. Even though he gives you fake DNS (or IP routing, another possibility) he can't present and prove possession of the key for a valid cert for D and the SSL/TLS handshake fails.

Unless of course you, or the supplier of your browser or OS or device on your behalf, trusts a CA that issues bogus certs, for any of a range of reasons. For example, you can find probably a dozen Q&A here and other stack sites about last year's Lenovo Superfish fiasco: they added software to a large number of Windows PCs that used their own CA to MitM your HTTPS connections for the claimed purpose of providing more relevant advertising -- but they exposed the (fixed) CA privatekey and then anybody else could MitM you. They had to publish tools to remove the offending software and CA cert, and to catch any that slipped through the browser and OS makers also blacklisted their cert.

Improve this answer
2
  • I really appreciate your extensive answer. So in short: One can't count on the subject when verifying a certificate (#). I have to trust the CAs in my root store in that, that they really check the CSR in depth and only sign certificates for nice guys. "attacker M can't either trick or force a trusted CA into wrongly issuing him a cert for domain D" 1) It does not have to be the same Domain, imagine google.de and googIe.de (2nd is with a big i). 2) If M sends a wrong RR (A record for google.de that points to a wrong IP) and (#) from above holds, M's attack would still work.
    – Hansi
    Sep 24, 2016 at 10:28
  • You rely on the CAs do their job, yes, as I said. If you actually request a connection to a similar-looking but wrong name, SSL/TLS/cert only protects your connection to what you asked for, not what you meant. This is called typosquatting and is a problem even without SSL/TLS. But if you do request the correct domainname, the browser will not be fooled by a cert for a similar looking name, it must match exactly -- and in your scenario it doesn't.
    – dave_thompson_085
    Sep 25, 2016 at 9:16
1

One reason that I care about is that two entities (Alice and Bob) can have certs from a CA I trust but that doesn't mean I trust Alice the same way that I do Bob. This is relevant when you think of servers but it's more clear when you look at it in the context of client certificates. The certificate is used to authenticate the client and we can do that because we trust the CA. But in order to know what rights (if any) that client has in a given context, I need to know who they are, not just where they got their cert signed. Simply knowing the CA isn't enough for that. It's true that if you don't have control over how the DNs are assigned, you can't really count on them so it's important to understand what level of identification you really need and whether the cert gives you that reliably.

Improve this answer
1

"Digital certificates map public keys to entities"

This is only true for Organization Validation (OV) and Extended Validation (EV) certificates. Domain Validation (DV) certificate only maps public keys to the "controller" of domain name, but gives no indication of the identity of the "controller". The OV and EV certificates validation processes, on the other hand, are designed to link a public key with a domain name and a registered business/organization identity.

Public Certificate Authorities are only allowed to put validated information in the Subject/DN of the certificate. In all major web browsers, savvy users can view all these certificate details by clicking on the padlock button in the URL bar.

This is why DV certificate only contains the domain name, since that's the only information that the CA has validated. An OV and EV certificate contains the business' legal name, the business' legal jurisdiction, and usually the business' unique registration number in a government business database (or some other qualified business databases). This registration number can be used by savvy users to look up the business in the relevant databases.

Sometimes a business' legal name is not necessarily the same as the name that the public knows the business as, and this is why some sites have strange names in their certificate. In this case, the business may be able to have a DBA (doing business as) name also attached in the certificate. The CA also need to be able to validate this alternate name before they will put it in the certificate.

The big problem with DN is that there's little standardization on what to put in there. This means that different CA puts slightly different things into the DN. While this is OK when the DN is read and verified by human, the lack of standard makes it difficult for automated program to use the DN to figure out what organization it is referring to.

Improve this answer

You must log in to answer this question.

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