TL;DR
Using Extended Validation (EV) certificates with a privately hosted Certificate Authority (CA) gives you greater control over your security, reduces reliance on public CAs, and can lower costs in the long run. However, it requires significant technical expertise to set up and maintain correctly.
1. Understanding EV Certificates
EV certificates are the highest level of SSL/TLS certificate validation. They require a more rigorous identity verification process than standard Domain Validated (DV) or Organization Validated (OV) certificates. This means browsers display extra information about the organisation, typically in the address bar – for example, showing the company name.
- Increased Trust: EV certificates build stronger trust with your users as they clearly show verified identity.
- Phishing Protection: The enhanced verification process makes it harder for attackers to obtain fraudulent certificates.
2. Why Use a Private CA?
Traditionally, you get EV certificates from public Certificate Authorities like Let’s Encrypt, DigiCert or Sectigo. A private CA is one you run yourself. Here’s why you might choose this route:
- Control: You have complete control over the entire certificate lifecycle – issuance, renewal, and revocation.
- Cost Savings: After initial setup, issuing certificates can be cheaper than repeatedly purchasing them from a public CA, especially for internal services or large deployments.
- Flexibility: You can tailor your certificate policies to meet specific security requirements.
- Internal Services: Ideal for securing internal applications and infrastructure where public trust isn’t needed but strong identity verification is still important.
3. Setting Up Your Private CA
This is the most complex part. You’ll need to choose a CA software package (e.g., OpenSSL, EJBCA, Smallstep) and set up a secure infrastructure.
3.1 Choosing CA Software
OpenSSL is powerful but requires significant manual configuration. EJBCA and Smallstep offer more user-friendly interfaces and automation features.
3.2 Infrastructure Requirements
- Dedicated Server: A dedicated, hardened server for your CA.
- HSM (Hardware Security Module): Strongly recommended to protect the CA’s private key. This is crucial for security.
- Secure Network: The CA server must be on a secure network with restricted access.
3.3 Generating Root Certificate
This is the foundation of your trust chain. Protect this key *extremely* carefully.
openssl req -x509 -newkey rsa:4096 -keyout ca.key -out ca.crt -days 36504. Issuing EV Certificates
Once your CA is set up, you can issue EV certificates.
4.1 Identity Verification
You must perform rigorous identity verification according to the EV guidelines (defined by the CA/Browser Forum). This typically involves:
- Legal Existence: Confirming the organisation is legally registered.
- Physical Address: Verifying the physical address of the organisation.
- Authorisation: Confirming the requestor is authorised to obtain a certificate for the domain.
4.2 Certificate Signing Request (CSR)
The applicant generates a CSR on their server.
openssl req -new -key private.key -out csr.pem4.3 Signing the CSR
Your CA signs the CSR to create the EV certificate.
openssl ca -signkey ca.key -cert ca.crt -in csr.pem -out ev_certificate.pem -days 3655. Deployment and Trust
Deploying your EV certificate is similar to deploying any other SSL/TLS certificate, but you also need to ensure clients trust your private CA.
5.1 Certificate Installation
Install the EV certificate on your web server (e.g., Apache, Nginx).
5.2 Trust Store Distribution
Clients must trust your root certificate. This can be achieved by:
- Internal Clients: Distribute the root certificate to all internal clients via Group Policy or other management tools.
- Public Facing Services: This is much harder and generally not recommended for public-facing services unless you have a very specific use case, as it requires users to manually install your CA’s root certificate.