Digital Certificates (part 2 of 2)

Part two continues on the topic of digital certificates.    One of the keys is private and the other is public.

Below are some useful examples and explanations from Novell:

But, how does this work on the Internet for transactions?

Trust is a tricky thing.  That is why we have certificate authorities.

In more detail:

There are different formats for certificates. X.509 is perhaps the most popular. RFC5280 covers the specifics of the X.509 certificate definition.

As an example, here is the definition of basic fields in X.509:

Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

   TBSCertificate  ::=  SEQUENCE  {
        version         [0]  EXPLICIT 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]  EXPLICIT Extensions OPTIONAL
                             -- If present, version MUST be v3

In more readable format:

  • Certificate
    • Version
    • Serial Number
    • Algorithm ID
    • Issuer
    • Validity
      • Not Before
      • Not After
    • Subject
    • Subject Public Key Info
      • Public Key Algorithm
      • Subject Public Key
    • Issuer Unique Identifier (Optional)
    • Subject Unique Identifier (Optional)
    • Extensions (Optional)
  • Certificate Signature Algorithm
  • Certificate Signature

This standard first started in 1988 and has widespread acceptance.  Public key certificates typically have a file extension of “cer”.  However, there are many variants (info from Wikipedia):

Common filename extensions for X.509 certificates are:

  • .pem – (Privacy Enhanced MailBase64 encoded DER certificate, enclosed between “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–“
  • .cer.crt.der – usually in binary DER form, but Base64-encoded certificates are common too (see .pem above)
  • .p7b.p7c – PKCS#7 SignedData structure without data, just certificate(s) or CRL(s)
  • .p12 – PKCS#12, may contain certificate(s) (public) and private keys (password protected)
  • .pfx – PFX, predecessor of PKCS#12 (usually contains data in PKCS#12 format, e.g, with PFX files generated in IIS)

To see the raw certificate data, Wikipedia has examples.  Public keys can come in different sizes and typically the bigger sizes are much harder to crack.  The default is usually 1024 bit (128 bytes) but lately it is recommended to have a 2048 bit public key (256 bytes).

Certificate authorities are only in the business of verifying the owners of public keys.  They do not generate the key pair (public and private) and only help to embed the public key in the certificate.  Private keys are never transferred unless the owner intends to export the key to another location.

Web browsers contain a list of CAs that they trust.  This is a partial list from FireFox:

And drilling down into more detail:

With web browsers, it is incredibly important to be trusted by a CA.  Otherwise SSL will fail and you will be unable to secure trusted communication for the sake of privacy or business transactions.

And, becoming a certificate authority is a difficult process.  CAs must go through annual audits (WebTrust) to be included in the web browser trusted list.  The top three CAs (VeriSign, GoDaddy, and Comodo) have 86% of the certificate business.

This Wikipedia diagram shows the creation and use of certificates.  The idea of Certificate Signing Request is introduced as part of getting the CA to sign the certificate request.

If you happen to be interested in the math of how PKI works, Wikipedia, as usual, has a good key exchange explanation.

This covers the basics of what certificates are all about.   Further posts will cover more specialized areas.


Live near Brisbane, Australia. Software developer currently focused on iOS and Android. Avid Google Local Guide

Tagged with: ,
Posted in Certificates, PKI
2 comments on “Digital Certificates (part 2 of 2)
  1. Jasper says:

    Could you please explain on ‘how’ or ‘who’ is checking for certificate validity in Windows operating system ? There’s a lot of certificate come pre-installed in Windows (root certs), by-the-way: some of them issued for companies that don’t exist 🙂 and every time I click on cert it shown as ‘valid’ and checked (including cert path – like in your example VeriSign Class 3 CA). So my question is:
    1) Who is checking for cert validity in Windows ?
    2) What is cert validity state in case when root CA (or user comp) is off-line ?

  2. jeffreymuir says:

    This was not an easy question to answer so I put it into the background tasks and unfortunately forgot about it. Sorry.

    The easy answer is that the certificates need to be managed/verified by the software that wants to use them. For example, Internet Explorer needs to worry about certificates for all HTTPS transactions. It uses CryptoAPI to prove that the certificates are good. Check out this IE6 documentation. This sort of makes sense but it seems to put too much pressure on the implementor.

    The root CA certificates in Windows are supposed to be fine for everyone. Some of the companies have been bought by others and some have gone out of business. In theory this is fine too as long as the private keys are protected. The expiry of the certificates makes sure that any mistake does not last forever.

    You can see the actual CryptoAPI Cert functions at Microsoft.

    Most of this is designed to work great offline. The only catch is coming across a multilevel chain between the certificate and the root CA certificate. The rule looks to be that it will automatically insert the intermediate CAs from certificates which are downloaded. There must be a field in the certificates that allows for URL specification of the parent certificate. I have only seen this a couple of times.

    There are bigger lists of root CAs that you can install from Microsoft. This looks to be a way to trust more things, especially government root CAs. Here is a Microsoft link about trusted root.

    It makes sense that certificates would work fine with IE even if it does not have all the intermediate CAs. It is in the business of downloading content so it would be online and able to pull down the missing certificates. This would not necessarily true for other applications.

Comments are closed.

Follow Red Circle Blog on
%d bloggers like this: