Getting a TLS Server Digital Certificate

What is TLS?

TLS stands for Transport Layer Security. It is specified in IETF RFC 8846, “The Transport Layer Security (TLS) Protocol Version 1.3”, August 2018. TLS is descended from an earlier standard called SSL (Secure Sockets Layer). Some people still refer to TLS as SSL but that actually refers to a much older, simpler protocol that is no longer in use (it was deprecated years ago).

TLS is inherently a Client/Server architecture used to connect one client to one server. The client initiates the connection and the server accepts and processes the connection. TLS adds encryption for privacy and authentication to identify one or both nodes to the other node.

With traditional TLS, only the server node needs a digital certificate which binds a public key to the fully qualified domain name of the server. The server also has a private key, which never leaves the server and must be protected from disclosure. Upon connection from the client, the server downloads its server certificate to the client. The client validates that certificate and then does a cryptographic challenge using its public and private keys. This authenticates the server to the client. The client creates a Symmetric Session Key (e.g. using AES) and securely shares it with the server. This key is used to encrypt all following traffic (in both directions) over that connection.

It is possible for the client node to also have a digital certificate that binds the public key to the identity of a person or device, as well as a corresponding private key which lives on the client computer and also must be protected from disclosure. The client certificate is uploaded to the server where it is validated followed by a cryptographic challenge. This happens during the TLS handshake and authenticates the client to the server. This will be covered in the next writeup. In the absence of a client certificate the client typically authenticates to the server with some form of username/password authentication, possibly combined with some kind of 2FA (Two Factor Authentication).

How do I get a Server (“SSL”) Digital Certificate?

You can create your own self-signed certificate (the digital signature on the certificate is signed by its own private key). This will work, and even allow the connection to be encrypted. However, there is no authentication or trust involved. You should not do any financial transactions on a site that uses a self-signed certificate.

You can even create your own certificate hierarchy, with root certificate and even an intermediate certificate. If you can convince users to install your root and intermediate certificates, this will work just like a “real” (trusted, or public hierarchy) certificate. Users should only install the root and intermediate certs of issuers they trust. Without those installed, your system will report an “untrusted certificate” and may refuse to connect. It is possible for an organization to create “private” hierarchy server certs using various products, and automatically install the necessary CA certs on all nodes in the organization.

Most people obtain a server certificate from a “public” (trusted) Certification Authority. All of them provide server, client and E-mail certificates. Most of them also offer code-signing certificates (needed only by software vendors) and Adobe compliant certificates (for digitally signing PDF documents). There are many CAs operating today, including:

There are also a number of resellers of digital certificates from one or more of the above Certification Authorities (a lot of them resell Sectigo certificates). Most sell both server, client and e-mail certificates. They are not a Certification Authorities (CA) themselves. They offer lower prices compared to buying directly from the CA, and some additional layer of support. The certificates are the exact same ones you would get directly from the CAs. Many also resell domain names. These include:

Levels of Identity Validation

There are different “levels” of server certificate validation available from all of these vendors depending on how strongly you validate your domain and/or company name. The more fields you validate, the more the higher the cost for your certificate.

Domain Validated (DV) Certificates

The basic level only involved verifying you own the domain name involved (e.g. All that goes into the Subject Distinguished Name in the certificate is the “CommonName” field (e.g. There are generally three ways to do this:

    • posting a document they provide on your website (only useful if this is for a web server) in a special location (not normally visible to website users)
    • replying to an email message sent to a “postmaster” account for that domain (e.g. – if you control the domain, you either already have such an email account or can create one
    • publishing a special CNAME record in the public DNS for the domain (this assumes you manage your DNS records)

Almost all CAs and resellers support the first two schemes, you may have to ask to use the DNS scheme. Some CAs will look up the organizational contact in the WhoIs database for that domain and contact them.

Organization Name Validation

For a little more money, you can also validate that you have rights to use your organization name in the server certificate (e.g. Sixscape Communications Pte Ltd). The CA will try to contact someone in authority at your organization (e.g. from your company registration or DUNS information), or require you to submit copies of some of your founding documents. If this is validated, the “O” field (e.g. O=Sixscape Communications Pte Ltd) will be added into the Subject Distinguished name in the certificate. You might also be able to add an Organizational Unit (OU) field (e.g. OU=PKI Operations). This provides the person surfing to your site a higher level of confidence that your site is the official one for your organization.

Enhanced Validation (EV) Certificates

The top level of validation requires your validating quite a few things, such as Locality (city), State, Country, etc. This would require submitting documents that validate each of those things (L, S and C fields in the subject distinguished name). Sixscape Communications has an EV certificate on its website. The Subject Distinguished Name from our certificate contains quite a few fields:

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

Anyone surfing to your website can see all of this information by clicking on the padlock security icon in the browser URL, then selecting “Certificate”, then “Details” and then “Subject”.

The STREET field is obvious. L = Locality (city), S = State, C = Country, SERIALNUMBER is our corporate registration number in Singapore. The other two fields are “OIDs” for organization type and legal jurisdiction.

If you want your website users to feel safe doing financial transactions (E-Commerce) or increase your website user’s confidence that this is really the official website for your organization, an EV certificate might be worth the extra effort and money.

Installing a Server Cert

Installation varies greatly based on the web (or other) server you are installing the certificate on.

In IIS you generally create the Certificate Signing Request in the IIS Admin tool. Go to the top item and select Server Certificates. On the right side, click Create Certificate Request.

Fill in items for the Subject Distinguished Name (SubjectDN). The Common name (CN) field should contain the Fully Qualified Domain Name of the server. Click Next.

Select appropriate CSP (probably RSA) and key length (probably 2048 bit). Click Next.

Specify the filename and click Finish. It will generate a public/private keypair and create a PKCS #10 Certificate Signing Request (CSR) from the supplied SubjectDN.

The CSR file looks like this (encoded in Base64 with PEM style delimiters)


That file can be uploaded to your Certification Authority. They will send you back the generated certificate. In the IIS admin tool, select Complete Certificate Request to link the new cert back to the private key that was created, and store the result as key material.

For Apache and other Open Source web servers, check online for how to create a CSR and private key, then install the key material (you will probably use the OpenSSL command line tool) then edit the configuration file in a text editor.