Let’s Encrypt is again special in that the response has a Content-Type:application/pkix-cert
header (but at least it’s in DER format like every other certificate). RapidSSL uses
Content-Type:text/plain.

The CA Issuers field sometimes points to the signing certificate (e.g. StartSSL) or to the root CA
(e.g. Comodo DV, which points to the AddTrust Root CA)

A hash identifying the CA used to sign the certificate. In theory the identifier may also be based
on the issuer name and serial number, but in the wild, all certificates reference the
subjectKeyIdentifier. Self-signed certificates (e.g. Root CAs, like StartSSL and Comodo
below) will reference themself, while signed certificates reference the signed CA, e.g.:

The basicConstraints extension specifies if the certificate can be used as a certificate
authority. It is always marked as critical. The pathlen attribute specifies the levels of
possible intermediate CAs. If not present, the level of intermediate CAs is unlimited, a
pathlen:0 means that the CA itself can not issue certificates with CA:TRUE itself.

In theory a complex multi-valued extension, this extension usually just holds a URI pointing to a
Certificate Revokation List (CRL).

Root certificate authorities (StartSSL, GeoTrust Global, GlobalSign) do not set this field. This
usually isn’t a problem since clients have a list of trusted root certificates anyway, and browsers
and distributions should get regular updates on the list of trusted certificates.

All CRLs linked here are all in DER/ASN1 format, and the Content-Type header in the response is
set to application/pkix-crl. Only Comodo uses application/x-pkcs7-crl, but it is also in
DER/ASN1 format.

Let’s Encrypt is so far the only CA that does not maintain a CRL for signed certificates. Major CAs
usually don’t fancy CRLs much because they are a large file (e.g. Comodos CRL is 1.5MB) containing
all certificates and cause major traffic for CAs. OCSP is just better in every way.