What information is signed by a Certification Authority?

What data does a CA sign?

I know that in a certificate there is plenty of information such a the serial number of the certificate itself, the X.509 version number, the user public key, the asymmetric algorithm to which the key belongs and its size, the user ID, the validity of the cert (both beginning and expiration day), CA ID and finally the digital signature and the algorithm used to generate it..

What information is signed with the CA private key? Is it just the (user ID || user public key) or something else?

I don't know if I need to specify that, but I man concatenation with the || symbol, but I don't know if the data is simply appended in sequence.

The information that is signed may differ by certificate, but basically the procedure can be found by looking at RFC 5280 and working downward:

4.1.1.3.  signatureValue

The signatureValue field contains a digital signature computed upon
the ASN.1 DER encoded tbsCertificate.  The ASN.1 DER encoded
tbsCertificate is used as the input to the signature function.  This
signature value is encoded as a BIT STRING and included in the
signature field.  The details of this process are specified for each
of the algorithms listed in [RFC3279], [RFC4055], and [RFC4491].

By generating this signature, a CA certifies the validity of the
information in the tbsCertificate field.  In particular, the CA
certifies the binding between the public key material and the subject
of the certificate.


Note that signature value is the signature put over the certificate by the CA here, it's not a digital signature over a document.

The next section contains a content description:

4.1.2.  TBSCertificate

The sequence TBSCertificate contains information associated with the
subject of the certificate and the CA that issued it.  Every
TBSCertificate contains the names of the subject and issuer, a public
key associated with the subject, a validity period, a version number,
and a serial number; some MAY contain optional unique identifier
fields.  The remainder of this section describes the syntax and
semantics of these fields.  A TBSCertificate usually includes
extensions.  Extensions for the Internet PKI are described in Section
4.2.


TBS in TBSCertificate stands for To Be Signed which makes things pretty clear.

To be more precise, the contents of the TBS certificate are

TBSCertificate  ::=  SEQUENCE  {
version         [0]  Version DEFAULT v1,
serialNumber         CertificateSerialNumber,
signature            AlgorithmIdentifier,
issuer               Name,
validity             Validity,
subject              Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
extensions      [3]  Extensions OPTIONAL



subjectPublicKeyInfo above contains the encoded public key.

And the list of extensions can be found by looking at the index:

    4.2. Certificate Extensions ....................................26
4.2.1. Standard Extensions ................................27
4.2.1.1. Authority Key Identifier ..................27
4.2.1.2. Subject Key Identifier ....................28
4.2.1.3. Key Usage .................................29
4.2.1.4. Certificate Policies ......................32
4.2.1.5. Policy Mappings ...........................35
4.2.1.6. Subject Alternative Name ..................35
4.2.1.7. Issuer Alternative Name ...................38
4.2.1.8. Subject Directory Attributes ..............39
4.2.1.9. Basic Constraints .........................39
4.2.1.10. Name Constraints .........................40
4.2.1.11. Policy Constraints .......................43
4.2.1.12. Extended Key Usage .......................44
4.2.1.13. CRL Distribution Points ..................45
4.2.1.14. Inhibit anyPolicy ........................48
4.2.1.15. Freshest CRL (a.k.a. Delta CRL
Distribution Point) ......................48
4.2.2. Private Internet Extensions ........................49
4.2.2.1. Authority Information Access ..............49
4.2.2.2. Subject Information Access ................51

• Are the contents of the TBS field simply binded together and given in input to the hash function? – M-elman Dec 17 '16 at 8:10
• ASN.1 DER encoding is already a unique encoding of these fields. There are some subtleties with regards to IMPLICIT fields and some people manage to get the encoding of the key usage wrong, but in principle the DER encoding is a canonical encoding: you can only get to one specific encoding given the various fields (no reordering or additional padding etc. allowed). I won't go any further into ASN.1 or DER here. And yes, this is input to the signature function which includes a hash function. – Maarten Bodewes Dec 17 '16 at 13:44