CODEWITHSUNDEEP
sslopensslcertificatessl-certificatex509certificate
g000ze
g000ze

Reputation: 289

Different output by openssl

I have been asking myself, how to interpret the output of openssl regarding certificates, depending on the option (-text or -purpose). Sometimes it is not clear to me, whether - for example - a certificate is meant to be a CA or not.

Example: 

openssl x509 -in /path/to/cert1.pem -purpose -noout
Certificate purposes:
SSL client : Yes
SSL client CA : Yes (WARNING code=3)
SSL server : Yes
SSL server CA : Yes (WARNING code=3)
...

But:

openssl x509 -in /path/to/cert1.pem -text -noout | grep CA

This shows no result. However:

openssl x509 -in /path/to/cert2.pem -purpose -noout 
Certificate purposes:
SSL client : Yes
SSL client CA : Yes
SSL server : Yes
SSL server CA : Yes
...

And:

openssl x509 -in /path/to/cert2.pem -text -noout | grep CA
CA:TRUE

Upvotes: 1

Views: 824

Answers (2)

Pak Uula
Pak Uula

Reputation: 3425

From the x509 documentation:

SSL Client CA

The extended key usage extension must be absent or include the "web client authentication" OID. Netscape certificate type must be absent or it must have the SSL CA bit set: this is used as a work around if the basicConstraints extension is absent.

It looks like your certificate has neither x509v3 extensions (basicConstraints nor extendedUsage). As @Reinier-Torenbeek stated, it means that your certificate is of x509 version 1 type.

Upvotes: 0

Reinier Torenbeek
Reinier Torenbeek

Reputation: 17383

From the limited output that you provide, it does seem that your cert1.pem is of type X509v1. As such, its -text output does not contain the X509v3 extension that show up in your grep result for cert2.pem.

Some support for this hypothesis starts at the output for cert1.pem, which includes

SSL client CA : Yes (WARNING code=3)

The OpenSSL documentation around the meaning of this warning is limited, but by checking its source code, starting at the apps/x509.c application, traces back to the following function:

static int check_ca(const X509 *x)
{
    /* keyUsage if present should allow cert signing */
    if (ku_reject(x, KU_KEY_CERT_SIGN))
        return 0;
    if (x->ex_flags & EXFLAG_BCONS) {
        if (x->ex_flags & EXFLAG_CA)
            return 1;
        /* If basicConstraints says not a CA then say so */
        else
            return 0;
    } else {
        /* we support V1 roots for...  uh, I don't really know why. */
        if ((x->ex_flags & V1_ROOT) == V1_ROOT)
            return 3;
        /*
         * If key usage present it must have certSign so tolerate it
         */
        else if (x->ex_flags & EXFLAG_KUSAGE)
            return 4;
        /* Older certificates could have Netscape-specific CA types */
        else if (x->ex_flags & EXFLAG_NSCERT && x->ex_nscert & NS_ANY_CA)
            return 5;
        /* can this still be regarded a CA certificate?  I doubt it */
        return 0;
    }
}

where you see code value 3 show up.

To verify whether this is the situation, just look at the first line in your text dump of the different certs, which will look like this:

Certificate:
    Data:
        Version: 1 (0x0)

Going back to the X509 tool documentation page, the following now makes sense:

If the certificate is a V1 certificate (and thus has no extensions) and it is self signed it is also assumed to be a CA but a warning is again given: this is to work around the problem of Verisign roots which are V1 self signed certificates.

Upvotes: 4

Related Questions