Digital Certificate

An X.509 Digital Certificate is a document (file) that contains several things, depending on the type of cert. A server (SSL) cert identifies a particular node connected to the Internet, and might have the following things in it:

    • A Subject Distinguished Name that uniquely identifies a person, device or computer (node), for example
    • An Issuer Distinguished Name that uniquely identifies the CA that issued the cert, e.g. CN=Sectigo RSA Domain Validation Secure Server CA, O=Sectigo Limited, L=Salfor, S=Greater Manchester, C=GB
    • A 128-bit serial number, e.g. 00bb06fab4d512a3dea09b19e54361050a
    • A start (ValidFrom) date, e.g. ‎Friday, ‎May ‎8, ‎2020 7:00:00 PM
    • An end (ValidTo) date, e.g. ‎‎Sunday, ‎May ‎9, ‎2021 6:59:59 PM
    • A public key (e.g. 2048 bit RSA key)
    • Key Usage Flags, e.g. Digital Signature, Key Encipherment
    • Enhanced Key Usage Flags, e.g. Server Authentication, Client Authentication
    • The URL where the Certificate Revocation List for this cert can be found
    • The URL where the OCSP server for this cert can be found (if any)
    • A Digital Signature created by the CA using their signing private key covering all of the above

A client cert identifies a particular person or device. The primary difference is the Subject Distinguished Name, which might be something like CN=Lawrence Hughes,, L=Frisco, S=Texas, C=US. It might also have slightly different usage flags, and if it is an S/MIME cert it will contain a Subject Alternative Name such as

There are various other things in some certs, but the above are the basic ones. The specification for Digital Certificates is in X.509, part of the OSI X.500 Directory Server specification. This specification has been adopted into the IETF RFC repository as RFC 5280, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, May 2008.

Without Digital Certificates, it would be easy to trick someone into using a bogus public key. This is called the public key substitution threat. With the public key embedded in a Digital Certificate, anyone can determine whether it is the correct public key for the person, node or device named in the Subject Distinguished Name, that the items in the SubjectDN have been validated to be correct and current, and that none of the information in the cert has been modified in any way since it was issued by the CA. This provides trust.

The CA also can revoke a certificate if it has been compromised (or for various other reasons). Users of certs from that CA can check the appropriate Certificate Revocation List, or on OCSP to determine the revocation status.

All of the equipment, legal agreements and trusted operators needed to securely issue and manage certificates are called a Public Key Infrastructure or PKI.

Subject Distinguished Name

One of the fields in an X.509 cert (the Subject Distinguished Name) uniquely specifies one person, device or Internet node that the public key belongs to. It can have various fields, each of which is a name/value pair, e.g. CN=Lawrence Hughes. Some of the fields are:

      • CN or CommonName, e.g. CN=Lawrence Hughes
      • E or Email, e.g.
      • OU or OrganizationalUnit, e.g. OU=IT
      • O or Organization, e.g. O=PKIEdu Inc.
      • L or Locality (city), e.g. L=Frisco
      • S or State (or province), e.g. S=Texas
      • C or Country, e.g. C=US

The applicant creates a public/private keypair, and supplies the above SubjectDN information in a PKCS10 Certificate Signing Request, along with their public key. The Registration Authority (RA) at the Certification Authority verifies all the submitted information (e.g by reviewing passports, billing statements, birth certificates, etc). The CA then creates an X.509 certificate from the CSR, adding in new items like start and end dates, Issuer Distinguished Name, URLs for obtaining the appropriate CRL or OCSP service, and usage flags, and finally digitally signs it. The CA may remove fields from the SubjectDN that they either didn’t or couldn’t validate. The issued certificate is returned to the applicant who links it back together with the private key.

There are several types of Digital Certificates including:

    • Server (or SSL) certificate – the SubjectDN identifies a specific Internet node, e.g. This is used to enable SSL/TLS on a server, which can authenticate the server to the client and exchange a symmetric session key.
    • Client certificate – the SubjectDN identifies a specific person or device, e.g. CN=Lawrence Hughes,, L=Frisco, S=Texas, C=US. This can be used for Strong Client Authentication (of the client to the server) during a TLS handshake. It can also be used for mutual strong authentication in PeerTLS.
    • S/MIME certificate – similar to a client certificate, with some additional fields needed for S/MIME secure E-mail.

Sources of Digital Certificates

There are many places from which you can obtain SSL or Server Digital Certificates. These can be used to enable SSL/TLS on various servers, including web (HTTPS), Email (SMTPS, IMAPS), LDAP (LDAPs), FTP (FTPS), etc. In general, users do not require a client cert to get privacy and server-to-client authentication (if the site uses username/password authentication for the client).

With most SSL/TLS secured servers, it is possible to configure it to support Strong Client Authentication (SCA) with a client digital certificate. In this case, each user will require a client digital certificate specific to them (which is trusted by the server). You can enable “Require Client Cert” (only SCA is allowed) or “Allow Client Cert” (if a user doesn’t have a client cert the server will fall back to username/password authentication).

Unfortunately many mobile based browsers do not support client certs, and even browsers that do support client certs have odd behavior – for example, once they start using one client cert there is no way to change to a different cert without killing every instance of that browser. Sixscape provides a mobile-device based alternative for doing SCA with any online service that combines Crypto Challenge with push notification. This also automates getting the client cert on your mobile device via IRP. Basically your phone becomes your authentication token. See SixToken for details. This can be bought directly from PKIEdu, from Sixscape Communications, or from one of our global resellers (currently GlobalSign and Entrust Datacard).

Sources of Server (SSL) Certs

For server certs, the major vendors are:

There are a number of resellers of certs from various CAs, where you can get better prices (especially from Comodo/Sectigo), including:

Many website hosting companies will be glad to sell you an SSL cert as part of their package, such as DreamHost (who host this site). I got the $15 a year DV cert from Sectigo, which was installed automatically (SSL certs on shared hosting can be a bit tricky to do yourself). DreamHost also will provide a free IPv6 address even for shared hosting (most hosting companies do not support IPv6 or if they do it is only on their high priced VPS offerings).

If you need more than a few server certs, all CAs have “Managed PKI” offerings, where you can verify your company and domain once, then manage the issuance of any number of certs yourself. You will still have to pay for each cert as issued. You can issue server certs and client/SMIME certs with these offerings.

There are different levels of certs for various needs. The basic level is “DV” or Domain Validation. The SubjectDN will have only Here you only need to prove that you have control over your domain through one of the following methods:

    • access to key email addresses such as
    • ability to upload a file into website
    • ability to publish a CNAME record in DNS for

For higher assurance, you can also validate ownership of your company name. There are various ways the CA can verify you have rights to use that corporate identity (e.g. DUNS, business registration documents, etc). For these certs the SubjectDN will contain, O=yourcompany.

For very high assurance (and an even higher price) you can get EV (Extended Validation) certs. You will have to provide numerous documents to the CA to validate more fields of the Subject DN. Some browsers will indicate an EV cert, for example by showing the site owner in green.

The cert on is an EV cert. If you check the SubjectDN on our cert, it includes the following fields (all of which we had to validate to the CA)

CN =
O = Sixscape Communications Pte Ltd
STREET = 33 Ubi Ave 3 #08-26
L = Singapore
S = Singapore
PostalCode = 408868
C = SG = Private Organization = SG

Sources of Client and S/MIME Digital Certs

Many of the above SSL Server Cert vendors also can provide client certs. If you are issuing client certs to your employees or customers, a Managed PKI solution may be the best bet.

Sixscape has a Managed PKI plan from DigiCert. As the administrator, you can issue certs with many fields in the SubjectDN (the domain name, O, L and C fields are specific to your Managed PKI plan). This cert works for SCA and S/MIME. The SubjectDN from my cert is:

E =
CN = Lawrence Hughes
OU = Administration
O = Sixscape Communications, Pte. Ltd.
L = Singapore
C = SG

You can obtain an S/MIME cert at Sectigo for about $12.95 per year (3 year plan). These are only email validated (they verify your identify by sending you an email, and the SubjectDN includes only E=<your email> (no CN=<your name>). I consider this weak identity validation, as it is possible to intercept other people’s email. I prefer client certs that include at least the applicant’s validated name (CN=<your name>) in addition to the email address (E=<your email>).

For an individual, I have had good luck getting client certs from They have email validated client certs for $20 a year (3 year plan), and “Pro” client certs with CN=<your name> and E=<your email> for $30 a year (3 year). They also have “Business” client certs that can also be used for Adobe PDF signing for $299 a year (1 year plan).

I got a “Class 3” client cert from I had to verify all of the included fields in the SubjectDN, which is very complete:

E =
CN = Lawrence Hughes
O = Sixscape Communications, Pte Ltd
L = Singapore
S = Singapore
C = SG

The Windows Certificate Store

Here “store” means a place where certificates are stored, not a place to buy certificates. This store is part of Windows, not any browser. This store has several “folders” in it, including:

    • Personal – certs that belong to you, and include a private key
    • Other People – certs that belong to other people (no private key), to use when sending encrypted messages
    • Intermediate Certificate Authorities – parent certs to the end-entity certs above, usually provided by Microsoft (although you can add more)
    • Trusted Root Certificate Authorities – parent certs to the intermediate certs above, usually provided by Microsoft (all CAs approved by WebTrust) but again you can add more (with a strong warning when you install)

IE included a tool to view and do limited management of the Certificate Store (Internet Options /  Content / Certificates):

It seems the the new MS Edge browser does not have anything equivalent. PKIEdu has a powerful replacement for this (SixWallet) that will run as a standalone app on any copy of Windows including Win10 and Windows Server (no browser is required for this to work). In addition to the things the old IE tool did, it allows integration with LDAP/AD and working with hardware cryptographic tokens (e.g. USB or smartcard). It also has extensive import/export options for certificates. If you have access to a CA that supports IRP, you can request and download certificates with SixWallet over IRP.

SixWallet also allows simple creation of a CSR and private key, with the ability to submit the CSR to an IRP-compliant CA over IRP. Even if you don’t have access to an IRP-compliant CA you can create a CSR and private key, and view the CSR in PEM format to cut and paste into a CA’s website. When you get the cert back, you can easily link it back to the private key, which is stored in protected form in SixWallet. This is far easier to use than working with the OpenSSL command line tool. You can request server certs, client certs, dual key pair certs, etc.

There will shortly be a way to buy and download SixWallet right from this website. I am also trying to list it on the Microsoft AppStore. As the author of this software I may be a bit biased, but I find this is one of my most useful and frequently used tools. I hope to create something similar for MacOS and at least something for Android and iOS (it’s written in C#.Net with WPF hence can be ported to Xamarin fairly easily).

Here is a copy of the manual for SixWallet. It contains quite a bit of additional information on Digital Certificates which you might find useful even if you don’t intend to license the software.

SixWallet v1.4.0 User Guide – 16 March 2020

Note that Firefox does have a simple Certificate Store viewer, but that is not for the Windows Certificate Store, it is for a Mozilla-specific Certificate Store, which is not used by most applications (primarily Firefox and Thunderbird). SixWallet works with the Windows Certificate Store.

S/MIME Certs for Microsoft Outlook

Microsoft made it really difficult to install S/MIME certs for an account in Outlook – it is actually too difficult for most people to manage. Sixscape created an addin for Outlook called SixMail, that vastly simplifies the process. Once the addin is installed, the next time you send an email, it will say “You don’t currently have an S/MIME cert, don’t worry I WILL GET ONE FOR YOU”. And about 10 seconds later you will have a public hierarchy S/MIME cert installed in your Outlook ready to use. It will automatically add the cert into AD (as well as your key material in PKCS12 form). It can optionally also escrow your key material for compliance issues. This allows the organization to recover encrypted emails even if the user’s private key is lost or destroyed.

This requires setting up some infrastructure, so is best suited to deployment in an organization. This also requires access to one of the IRP-enabled CAs we support, like GlobalSign or Entrust Datacard. This will be set up by our deployment team as part of the contract. I can resell this product and arrange for deployment anywhere.

We also support private hierarchy S/MIME using certs from your own EJBCA or PKI-In-A-Box. Contact us for other options (we can add IRP to almost any CA).

SixMail makes secure E-mail (with just signing or signing and encrypting) easy and safe enough for any organization to use.

A Word on Let’s Encrypt

I am not a fan of Let’s Encrypt. The certs are free, but have to be renewed every 90 days. Many Content Management Systems (e.g. WordPress) can automate getting these certs (e.g. “Really Simple SSL” plugin). A while back they had to reissue millions of cert because they had used non-compliant serial numbers. There is no source of revenue to cover the costs of running a full PKI (e.g. good revocation support).

There have been some issues with fraudulent issue, as you might have guessed. I would not be surprised to see Let’s Encrypt lose its WebTrust certification at some point, at which points its certs will no longer be trusted by any software.

I don’t have much confidence in the security of sites that use Let’s Encrypt certs. On this site, I opted to get a real Comodo cert instead of the free Let’s Encrypt cert. I validated my control of domain by adding a CNAME resource record into DNS (which I manage for The SubjectDN does only show but at least its not from Let’s Encrypt.

Basically a Let’s Encrypt protected site does provide privacy (via encryption) but the authentication normally provided by a real cert is very weak or nonexistent. Any user of your site that understands security may not have much confidence in the security of your site if you use Let’s Encrypt.

If you feel comfortable with using a Let’s Encrypt cert, they do work for now. There are millions of people using these. Don’t be surprised if WebTrust yanks their certification at some point.