1

During SSL server validation, it seems that the only fields of X509 certificates found in trust stores that are actually used are the "Common Name" and the "Public Key".

I'm not talking about any specific certificate validation implementation, but let's use OpenSSL as an example.

It seems that normal checks that happen to intermediate CA certificates do not apply to those present inside the anchor store, for example that basic constraints are not checked, dates are not checked, cipher weakness is not checked etc.

So I have two questions:

  1. Is the behavior I described correct? Are there any other fields being used?
  2. Should such 'extras' be checked according to the relevant RFCs ? From a casual read, it seems that everything in the anchor store is a priori trusted; no further checks should be done. This means that a CA certificate that lacks the CA:true constrain can issue other certificates and be the root of a valid chain. It also means that a CA certificate that has expired can also be root of a valid chain. Thoughts?
Improve this question
4
  • 2
    Why do you think that only those fields are checked?
    – Neil Smithline
    Dec 9, 2015 at 4:35
  • "cipher weakness" - if you mean hash function weakness, it isn't checked. You already trust the certificate by definition, whether it has a proper hash or not. So it's quite pointless to verify it (or to replace SHA-1 with SHA-2).
    – kubanczyk
    Dec 9, 2015 at 9:34
  • @NeilSmithline The SubjectName field is checked when the lookup is done to figure out if the last intermediate CA certificate in a received chain has a root CA present in the trust store. The public key is obviously used to verify the signature of that last intermediate CA certificate. In my tests, no other fields have any significance whatever their content.
    – Georgi
    Dec 9, 2015 at 10:42
  • 1
    @kubanczyk I understand the point, per the RFC, that it is probably pointless to verify anything in the certificates inside the trust store; as they are trusted by definition. However it seems counter intuitive if expired root certs or if certificates lacking the CA:true constraint can be used to form valid chains without errors. Isn't it?
    – Georgi
    Dec 9, 2015 at 10:44

1 Answer 1

Reset to default
2

This means that a CA certificate that lacks the CA:true constrain can issue other certificates and be the root of a valid chain

From my experience at least OpenSSL will verify that the CA:true flag is set, i.e. that the certificate can be used as CA at all. But I doubt that it checks expiration. It does not check for revocation since root CA are usually self-signed anyway thus revocation check would be impossible (you cannot trust a certificate to issue a revocation if you don't know yet if you can trust the certificate).

EDIT: based on the feedback of @Georgi it looks like that it will assume that the certificate can sign others if no constraints are set. But if an explicit CA:FALSE is set on the issuer certificate validation of certificates signed by this issuer will fail.

Improve this answer
6
  • I manually created a self-signed certificate without the CA:true basic constraint and inserted it into openssl trust store. I then used it to sign a server certificate. OpenSSL was happy to verify the server certificate without errors; thus the constraint is not checked.
    – Georgi
    Dec 9, 2015 at 10:40
  • @Georgi: I don't know how you tested but I created a certificate without CA flag and used this to sign a server certificate. Then I started a server using this server certificate. Using openssl s_client -CAfile.. resulted in a verify error (21 - unable to verify the first certificate). If I instead created the signer certificate with CA:true then verification succeeded. So for me it looks like CA:true is checked when validating the certificate, at least in the context of TLS.
    – Steffen Ullrich
    Dec 9, 2015 at 11:39
  • This is very interesting. I see you have CA:False which is different to what I did; in my tests I didn't have any basic constraints in the certificate. This is the same case as the recent eDellRoot incident; that certificate didn't have basic constraints, yet the OS trusted it fully to do validation. Could you share the commands you used to generate the CA cert, and also perform the test I'm mentioning here?
    – Georgi
    Dec 9, 2015 at 12:01
  • @Georgi: the script to create the certificates is here. And testing can simply be done with openssl s_server and s_client. For now I have not tested with a certificate without any constraints because the class I use does not support this (yet).
    – Steffen Ullrich
    Dec 9, 2015 at 12:15
  • @Georgi: you are right - if the "CA" has no constrains at all (X509v1 certificate) then it is assumed that it can sign. New code for creating all 3 kinds of certificates for testing see here.
    – Steffen Ullrich
    Dec 9, 2015 at 12:33

You must log in to answer this question.

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