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. sixscape.com). All that goes into the Subject Distinguished Name in the certificate is the “CommonName” field (e.g. CN=www.sixscape.com). 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. email@example.com) – 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 = www.sixscape.com OU = COMODO EV SSL O = Sixscape Communications Pte Ltd STREET = 33 Ubi Ave 3 #08-26 L = Singapore S = Singapore PostalCode = 408868 C = SG 126.96.36.199 = Private Organization 188.8.131.52.4.1.3184.108.40.206.3 = SG SERIALNUMBER = 201414391K
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)
-----BEGIN NEW CERTIFICATE REQUEST----- MIIEaDCCA1ACAQAwbjELMAkGA1UEBhMCVVMxDjAMBgNVBAgMBVRleGFzMQ8wDQYD VQQHDAZGcmlzY28xEjAQBgNVBAoMCUh1Z2hlc05ldDELMAkGA1UECwwCSVQxHTAb BgNVBAMMFHdzMS51cy5odWdoZXNuZXQub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAq64EyPmynjJr7yrI2+h3MkUAsfNYq0Gwy1dq1RdpjqlK0zY5 ZxmeNpOHdHbu1Cut8Dp9ShA27BsKWlHKjsiECaV3rfxbR3ODL7uIaoZqyfbu/wXC /ifLjxbaqrjdtYS0L9tocYDyq040HQhEbSRXem+J7YpEUxOFQyIiPrG+nTmPG50v R/hwyfBWlZTCP/j2ba5flFtuQ6h1+kwml2hL9a1WSUhNsDi+7hylNdpD6JsxEcUo b9JlNxPL2fW5sFssy9WRIGGJGAqek810Z1LLvCERIL8hk0SnHziXhWJOkNm/Qmko GI98Obbqn1lZum4PXpp/SND4VUnpEGrSvpvjGQIDAQABoIIBszAcBgorBgEEAYI3 DQIDMQ4WDDEwLjAuMTkwNDIuMjBNBgkrBgEEAYI3FRQxQDA+AgEFDBZMRUhQQy51 cy5odWdoZXNuZXQub3JnDBRIVUdIRVNORVQtVVNcbGh1Z2hlcwwLSW5ldE1nci5l eGUwcgYKKwYBBAGCNw0CAjFkMGICAQEeWgBNAGkAYwByAG8AcwBvAGYAdAAgAFIA UwBBACAAUwBDAGgAYQBuAG4AZQBsACAAQwByAHkAcAB0AG8AZwByAGEAcABoAGkA YwAgAFAAcgBvAHYAaQBkAGUAcgMBADCBzwYJKoZIhvcNAQkOMYHBMIG+MA4GA1Ud DwEB/wQEAwIE8DATBgNVHSUEDDAKBggrBgEFBQcDATB4BgkqhkiG9w0BCQ8EazBp MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwCwYJYIZIAWUDBAEqMAsG CWCGSAFlAwQBLTALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEFMAcGBSsOAwIHMAoG CCqGSIb3DQMHMB0GA1UdDgQWBBRg/WgqGomPfctzjr6zCvZSsDoLGTANBgkqhkiG 9w0BAQUFAAOCAQEAQ8J72aKEc1l2ITgtVPyrjb0AyOOo7wMl2/PSgJPsVc+F1Xc8 ObnfmxMkM+wAJPJ0vuXqoyQj5+G5+xG/V7sWQvX1YecoSYDOxOA5I8hUVFReXtgR Kd0s5U261WROVDT7uGFqatRvGeGFpYaqHb4aWiLzm8iWP5RVyeqoi5rqwtJyHVqb Dh2YImlHU3VIsCzIHT78nBjrvaI8atQ2EjDMB+F1ID31oes/NniSsmjCxZnU57XI 5WCJ5JhJKxMSS45DWoYEZcJu2ztHng50P6mSP/v1rSJFceDGA43gIb0mcsY5ROK5 lHGsTS1JDwAuzhq8TWfIdUdJA4EufcMZA/qjRg== -----END NEW CERTIFICATE REQUEST-----
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.