Get the attributes of a certificate with entity validation

freekmurze commented 7 years ago

I've created a package that can download all the certificates in the trust chain. Under the hood X509 is used

Certificates that provider only domain validation work perfectly. Unfortunately this does not work with certificates with entity validation.

In those cases X509 throws an error 1.3.6.1.4.1.11129.2.4.2 is not a currently supported extension. More info here: https://github.com/spatie/ssl-certificate-chain-resolver/issues/6

Also, X509 does not like Let's Encrypt certificates: https://github.com/spatie/ssl-certificate-chain-resolver/issues/5

I'd appreciate any help in getting this to work in the ssl-certificate-chain-resolver package.

terrafrost commented 7 years ago

Does https://github.com/phpseclib/phpseclib/pull/1076 fix the issue for you?

Also, could you post a cert that has that extension? Reading the RFC can sometimes be a poor substitute for being able to actually look at a real world example.

bantu commented 7 years ago

@terrafrost Here's a Let's Encrypt certificate.

freekmurze commented 7 years ago

@terrafrost using dev-master I was able to get the properties of a certificate issued by Let's Encrypt. Thanks.

Do you know how, using X509, to get the properties of this certificate downloaded from https://coolblue.be?

terrafrost commented 7 years ago

The certificate you linked to decoded just fine for me. The 1.3.6.1.4.1.11129.2.4.2 extension didn't decode but the cert itself did. The 1.3.6.1.4.1.11129.2.4.2 extension... is complicated. Quoting RFC6962

   At least one SCT MUST be included.  Server operators MAY include more
   than one SCT.

   Similarly, a certificate authority MAY submit a Precertificate to
   more than one log, and all obtained SCTs can be directly embedded in
   the final certificate, by encoding the SignedCertificateTimestampList
   structure as an ASN.1 OCTET STRING and inserting the resulting data
   in the TBSCertificate as an X.509v3 certificate extension (OID
   1.3.6.1.4.1.11129.2.4.2).  Upon receiving the certificate, clients
   can reconstruct the original TBSCertificate to verify the SCT
   signature.

   The contents of the ASN.1 OCTET STRING embedded in an OCSP extension
   or X509v3 certificate extension are as follows:

        opaque SerializedSCT<1..2^16-1>;

        struct {
            SerializedSCT sct_list <1..2^16-1>;
        } SignedCertificateTimestampList;

   Here, "SerializedSCT" is an opaque byte string that contains the
   serialized TLS structure.  This encoding ensures that TLS clients can
   decode each SCT individually (i.e., if there is a version upgrade,
   out-of-date clients can still parse old SCTs while skipping over new
   SCTs whose versions they don't understand).

At the top of that RFC it says this:

Data structures are defined according to the conventions laid out in
   Section 4 of [RFC5246].

RFC5246 defines TLS v1.2.

Basically, I think fully supporting that extension is gonna be complicated. For the time being I think I'll let the current behavior of decoding the cert - but not the extension - stand.

phpseclib / phpseclib

Get the attributes of a certificate with entity validation #1073