Certificate Authority Project

Project Concluded:   January 25, 2023

DB Reference:   dc_security_ca

Last Updated:   September 26, 2023

Digital certificates have become ubiquitous today. As the number of services increases, there is a growing demand for TLS certificates. Some of these certificates are for public access, which we can obtain from public CAs like DigiCert or Let's Encrypt. However, the majority of the requirements are for internal purposes, such as securing management interfaces, VPN or proxy connections, and inter-communications between services/servers. It is neither affordable nor practical to obtain certificates from public CAs for these purposes. Thus, having our own CA is necessary.

As of April 2023, the system has the following specification:

Root CA: 1 * 2 Core CPU & 2G Memory Virtual Server(Debian 11)

CRL Web: 1 * 2 Core CPU & 2G Memory Virtual Server(Debian 11)

OCSP Responder: 1 * 4 Core CPU & 6G Memory Virtual Server(Windows Server 2019)

Software: OpenSSL + Microsoft Certification Authority

The aim of this project is to provide a complete solution for internal services such as management interfaces and proxies, serving as a full replacement for public CAs. The goal is to deploy a root certificate on each domain machine and have all future certificates automatically trusted.

Currently, this project comprises four parts: a root CA, an intermediate CA used to sign general-purpose certificates, another intermediate CA used to issue certificates for domain computers, and a certificate validation system (including CRL and OCSP).

The root CA is the most important certificate in terms of trust. After examining several public CAs' certificates, I found that most CAs are valid for at least 20 years, and the key size varies from 2048 to 4096. I had a concern about key size and performance, but after conducting some research, I found that it doesn't matter that much. Eventually, I decided to generate a 4096-bit root certificate valid for 20 years.

During my research on root CAs, I realized that security is a critical problem. Therefore, I have done my best to implement isolation and security features, including the use of a hardware key.

This CA was named "Aurora Studio League Root CA - R1" and the certificate can be downloaded here

There are currently four intermediate CAs: the ASL Domain Validation Security CA for general issuance, the ASL Internal Services CA - ad1 for ad1 domain usage, the ASL Internal Services CA - ad2 for ad2 domain usage, and the ASL VPN Authentication Security CA for VPN client authentication.

The Domain Validation Security CA is responsible for issuing general certificates, such as x509 certificates used for web management interfaces. I have created a template to issue such certificates using Subject Alternative Names to facilitate the process. In the future, I'm planning on developing a script to automate this process.

You can download the certificate for this CA at here

The ASL Internal Services CA is used for domain purposes only. This one was integrated with a Microsoft Certification Authority, which handles the issuing policy for the entire ad1 domain. For now, the main usage for this is to automatically issue RDP (Remote Desktop) certificates for domain-joined machines. This will eliminate the annoying prompt when connecting to each other using RDP, or from external computers that have the root CA installed.

You can download the ca certificate for ad1 at here

You can download the ca certificate for ad2 at here

The ASL VPN Authentication Security CA is responsible for issuing certificates to VPN clients. This will provides a seamless and highly-secure VPN authentication process to the users.

You can download the certificate for this CA at here

Currently, the certificate validation system has two parts: a CRL (Certificate Revocation List) distribution point for all three CAs, and an OCSP (Online Certificate Status Protocol) responder for the domain CA.

The CRL distribution point is hosted on a separate VM, which sits behind the core proxy and only provides web functions. The CRL files are stored on one of the storage backends, and the CAs will push signed CRL files to the storage backend every 10 days automatically. This minimizes the possibility of being hacked at my current level of ability and retains the flexibility of updating the CRL automatically.

Currently, the OCSP responder is only active for the ad1 & ad2 domain due to Microsoft RDP's requirement for an active OCSP responder to verify certificates. Without it, a valid CRL will still produce a certificate error. It's possible that in the future, additional CAs will also have an OCSP responder deployed.

The root CA was deployed via GPO policy to all domain-joined computers, with the exception of a few external machines such as personal workstations. For Linux machines, the root certificate was only added manually when required.

I am considering adding more CAs for different purposes, such as Extended Validation or Email/Code signing in the future. Another task on my list is implementing an OCSP responder for all CAs. I'm also planning to explore adding more extensions, similar to those used by public CAs, once I have a better understanding of their purposes.

Email

• [email protected]
• [email protected]