Purpose of an SSL/TLS Certificate
An SSL/TLS certificate provides an encrypted connection between a user's browser and a web server. When an SSL/TLS is in place, a user can be assured that all the data that's exchanged between the browser and the web server is protected while in transit, using high-level encryption. It also serves as proof that the certificate holder's identity has been validated by a trusted third-party Certificate Authority (CA). Without an SSL/TLS in place, any data that passes between a user's browser and a web server is highly vulnerable to being intercepted by a malicious third party, commonly known as a "man in the middle" attack.
Purpose of this Document
This document explains the process of requesting, issuing, and deploying SSL/TLS certificates, focusing on the most common scenario: browser-based applications in on-premises installations. The details of this process may vary. In most cases, Pasco County IT staff can handle the entire process, but sometimes we have to include outside parties, such as vendors. This scenario assumes that it's done entirely by our internal IT people.
The Process
Requesting a new SSL/TLS Certificate in TDX
When a new SSL/TLS certificate is needed, a Requestor must submit a ticket in TDX, assigning it to the Security Team. If there's an existing project ticket in TDX, you can simply add a single task to that project ticket and assign it to the Security Team. They'll take it from there, creating the additional tasks as needed.
The only information the requestor will need to provide is 1) The Common Name for the certificate, and 2) If the application will host a failover/redundant server.
- Common Name: this is the unique part of the URL that allows people to navigate to a specific location and makes it easy to identify what the application or website is. Choose a name that is simple and consistent with the naming conventions of similar sites for your application. In each example below, the part highlighted in yellow represents the customizable section of the common name.
- For a Public Site on the World Wide Web (WWW)
"Need SSL certificate for webeoc.pascocountyfl.net". This is an example of a request for an SSL that's needed on a public-facing site, which can be accessed by anyone on the web.
- For a Private Site on the Pasco County BOCC Local Area Network (LAN)
"Need SSL certificate for: tylerweb.pascocountyfl.lan" This is an example of a request for an SSL that's needed on a private site, which can only be accessed from inside our firewall.
- Failover/Redundant Server: this is important to communicate up front, so that Production Support can make the correct configurations when generating a CSR (see Certificate Creation process below). If a failover/redundant server will be used, then Production Support must select “Make private key exportable” when creating the CSR. This action allows the certificate to be copied to the failover/redundant server, with its associated private key. If this step is missed, Production Support will have to re-issue a new CSR to account for the architecture.
Certificate Creation: From CSR to Binding
Once the Security Team takes ownership of the TDX ticket, they will assign three tasks, which must be done in the order as listed below:
1. CSR Generation
The Production Support Team will generate a CSR (Certificate Signing Request). This is done from the application's web server using the MMC (Microsoft Management Console). Once the CSR is ready, Production Support will close this task and update TDX to notify Security as to where the CSR can be found.
2. Certificate Creation
The Security Team will create the new SSL/TLS certificate from within the SCM (Sectigo Certificate Manager). When creating the new cert, Security will use the SCM to input the CSR, set the term, and select one of our cert profiles (such as public or private). Sectigo then provides us with the new cert (via the SCM), and Security closes this task while updating TDX to notify Production Support as to where the cert can be found.
3. Binding the Certificate
Production Support will now bind the certificate to the web server.
- First, they add the cert to the server's cert store using MMC*.
*Sometimes the Security Team will handle installation of the cert to the server's cert store, but they never do the binding.
- Then they put in a change request in TDX to notify the department that the change is occurring. Once the Change Board approves the change request, they can proceed to the next step.
- Production Support will now bind the certificate to the server using IIS, which means the cert is now fully operational.
- Finally, Production Support will close this task in TDX.
Glossary
SSL (Secure Socket Layer) & TLS (Transport Layer Security)
SSL is a deprecated protocol that's no longer used. It's been replaced by TLS, which has stronger encryption algorithms than SSL. Although the SSL acronym is still widely used due to its historical significance, the protocol in use today is (TLS). TLS is a security protocol from the IETF (Internet Engineering Task Force) that is used to create an encrypted connection between the user's browser and a Web server. It's also used in some proprietary applications that need to create a secure connection between a server and a client, such as VPN software.
PKI (Public Key Infrastructure)
A public key infrastructure is a system for the creation, storage, and distribution of digital certificates which are used to verify that a particular public key belongs to a certain entity. The PKI creates digital certificates which map public keys to entities, securely stores these certificates in a central repository and revokes them if needed. PKI is used to ensure the confidentiality, integrity, and availability of electronic transactions.
CA (Certificate Authority)
A certificate authority is a trusted entity that issues digital certificates to verify the identity of websites, users, computers, and organizations. CAs are a critical part of the internet's public key infrastructure (PKI) and help to ensure the security of the internet.
CSR (Certificate Signing Request)
In public key infrastructure systems, a certificate signing request is a message sent from an applicant to a certificate authority to apply for a digital identity certificate (for use in the SSL/TLS protocol). It usually contains the public key for which the certificate should be issued, identifying information and integrity protection.
SCM (Sectigo Certificate Manager)
SCM is the web console where the Security Team manages our certificates. Sectigo is the CA that we've contracted with, to fulfill all our SSL/TLS needs. Using the SCM, we're able to request new certs and manage our existing certs. This service includes automation tools, notifications of expiration, cert renewals, cert revocations, and so on. The Security Team is the SME/owner of the SCM.
MMC (Microsoft Management Console)
MMC is a component of Microsoft Windows that provides system administrators and advanced users an interface for configuring and monitoring the system. It offers numerous "snap-in" options, which are tools that can be added to the MMC to manage various services. For this specific use case, a certificate snap-in is used to manage the certificates on a system, which also includes generating CSRs.
IIS (Internet Information Services)
IIS is the Microsoft web server application for hosting websites. It is NOT the operating system for the server, but rather an application that runs within the Windows Server OS.