Secure Socket Layer
User's Guide
Version 3.10.7

Chapters

• The SSL Protocol
  • Top of chapter
  • SSL Connections
  • Certificates
  • Encryption Algorithms
  • SSL Handshake
  • Authentication
• Using the SSL application
  • Top of chapter
  • The ssl Module
  • A Client-Server Example
• PKIX Certificates
  • Top of chapter
  • Introduction to Certificates
  • PKIX Certificates
• Creating Certificates
  • Top of chapter
  • The openssl Command
  • An Example
• Using SSL for Erlang Distribution
  • Top of chapter
  • Introduction
  • Building boot scripts including the SSL application
  • Specifying distribution module for net_kernel
  • Specifying security options and other SSL options
  • Setting up environment to always use SSL
• Licenses
  • Top of chapter
  • OpenSSL License
  • SSLeay License

3 PKIX Certificates

3.1  Introduction to Certificates

Certificates were originally defined by ITU (CCITT) and the latest definitions are described in X.509, but those definitions are (as always) not working.

Working certificate definitions for the Internet Community are found in the the PKIX RFCs rfc3279and rfc3280. The parsing of certificates in the Erlang/OTP SSL application is based on those RFCS.

Certificates are defined in terms of ASN.1 (X.680). For an introduction to ASN.1 see ASN.1 Information Site.

3.2  PKIX Certificates

Here we base the PKIX certificate definitions in RFCs rfc3279and rfc3280. We however present the definitions according to SSL-PKIX.asn1 module, which is an amelioration of the PKIX1Explicit88.asn1, PKIX1Implicit88.asn1, and PKIX1Algorithms88.asn1 modules. You find all these modules in the pkix subdirectory of SSL.

The Erlang terms that are returned by the functions ssl:peercert/1/2, ssl_pkix:decode_cert/1/2, and ssl_pkix:decode_cert_file/1/2 when the option ssl is used in those functions, correspond the ASN.1 structures described in the sequel.

Certificate and TBSCertificate

Certificate  ::=  SEQUENCE  {
     tbsCertificate       TBSCertificate,
     signatureAlgorithm   SignatureAlgorithm,
     signature            BIT STRING }

TBSCertificate  ::=  SEQUENCE  {
     version         [0]  Version DEFAULT v1,
     serialNumber         CertificateSerialNumber,
     signature            SignatureAlgorithm,
     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
                          -- If present, version MUST be v3 --  }

Version  ::=  INTEGER  {  v1(0), v2(1), v3(2)  }

CertificateSerialNumber  ::=  INTEGER

Validity ::= SEQUENCE {
     notBefore      Time,
     notAfter       Time  }

Time ::= CHOICE {
     utcTime        UTCTime,
     generalTime    GeneralizedTime }
      

The meaning of the fields version, serialNumber, and validity are quite obvious given the type definitions above, so we do not go further into their details.

The signatureAlgorithm field of Certificate and the signature field of TBSCertificate contain the name and parameters of the algorithm used for signing the certificate. The values of these two fields must be equal.

The signature field of Certificate contains the value of the signature that the issuer computed by using the prescribed algorithm.

The issuer<c> and <c>subject fields can contain many different types av data, and is therefore considered in a separate section. The same holds for the extensions field. The issuerUniqueID and the subjectUniqueID fields are not considered further.

TBSCertificate issuer and subject

Name ::= CHOICE { -- only one possibility for now --
      rdnSequence  RDNSequence }

RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

DistinguishedName ::=   RDNSequence

RelativeDistinguishedName  ::=
                    SET SIZE (1 .. MAX) OF AttributeTypeAndValue

AttributeTypeAndValue ::=  SEQUENCE {
        type    ATTRIBUTE-TYPE-AND-VALUE-CLASS.&id
\011\011({SupportedAttributeTypeAndValues}),
        value   ATTRIBUTE-TYPE-AND-VALUE-CLASS.&Type
\011\011({SupportedAttributeTypeAndValues}{@type}) }

SupportedAttributeTypeAndValues ATTRIBUTE-TYPE-AND-VALUE-CLASS ::= 
\011{ name | surname | givenName | initials | generationQualifier |
\011  commonName | localityName | stateOrProvinceName | organizationName |
\011  organizationalUnitName | title | dnQualifier | countryName |
\011  serialNumber | pseudonym | domainComponent | emailAddress }      

TBSCertificate extensions

The extensions field of a TBScertificate is a sequence of type Extension, defined as follows,

Extension  ::=  SEQUENCE  {
     extnID      OBJECT IDENTIFIER,
     critical    BOOLEAN DEFAULT FALSE,
     extnValue   ANY }      

Each extension has a unique object identifier. An extension with a critical value set to TRUEmust be recognised by the reader of a certificate, or else the certificate must be rejected.

Extensions are divided into two groups: standard extensions and internet certificate extensions. All extensions listed in the table that follows are standard extensions, except for authorityInfoAccess and subjectInfoAccess, which are internet extensions.

Depending on the object identifier the extnValue is parsed into an appropriate welldefined structure.

The following table shows the purpose of each extension, but does not specify the structure. To see the structure consult the PKIX1Implicit88.asn1 module.