Hey there! If you manage more than a handful of websites and secure services for your organization, this guide is for you.
Keeping on top of all those SSL/TLS certificates can become tedious fast. But leveraging a versatile technology called Subject Alternative Name (SAN) certificates can greatly streamline encryption across your environment.
By the end of this guide, you’ll understand:
- How SAN certificates consolidate multiple domains into one cert
- The many benefits of the SAN approach over traditional SSL options
- Step-by-step instructions for generating SAN certificate signing requests yourself
- Tips for managing and automating SAN certificates
So if you’re ready to level up your understanding of multi-domain certificates, let’s get started!
The Rise of Encrypted Web Traffic
SSL/TLS encryption has exploded across the web over the last decade. Recent statistics show:
- 80% of web traffic is now protected by HTTPS encryption
- The number of issued SSL/TLS certificates grows by over 30% annually
- 35%+ of sites use multi-domain certificates able to handle more than one domain
The reasons for this encryption boom are plenty: consumer expectations for security, data privacy laws mandating communication protections, and improved search engine rankings for HTTPS sites.
Anatomy of an SSL/TLS Certificate
But before we explore the game-changing convenience of SAN certificates, let’s demystify what these digital certificates actually contain:
- Public Key: Enables encryption for data sent to the certificate’s domains
- Domain(s) Secured: The website URL(s) authenticated by the certificate
- Issued To: Details on the validated organization (common name, location, etc.)
- Validity Period: Length of time before certificate expiration (typically 1-2 years)
- Issuer: Trusted certificate authority (CA) who verified and signed the cert
Additional metadata further ensures the certificate securely does its job:
- Serial Number: Unique ID assigned by the CA
- Signature Algorithm: Cryptographic function used by CA to sign and validate
- Fingerprints: Secure hash identifiers enabling quick certificate recognition
- Certificate Chain: Linkage to root and intermediate issuing CAs establishing a chain of trust
These components come together to form the backbone of secure internet communications. But while encryption relies on certificates under the hood, website owners simply want the most affordable and convenient way to enable HTTPS security for all their domains.
That need for simplified SSL scalability is exactly what makes SAN certificates so useful compared to traditional single-domain certificates.
Unlocking the Potential of SAN Certificates
Subject Alternative Name certificates provide immense value by consolidating multiple domains into one manageable SSL/TLS certificate.
The key benefits this multi-domain approach offers include:
Lower Costs
Purchasing and renewing a single SAN certificate costs significantly less than individual certs for each domain. By managing fewer overall certificates, you reduce fees and overhead.
For example, securing six domains with individual SSL/TLS certs at $60 per cert annually costs $360 total. But a SAN certificate accommodating all six domains could lower the yearly cost to around $150 – slashing expenses by almost 60%!
Enhanced Security Consolidation
Concentrating multiple sites into one trusted certificate tightens up security administration around your web presence. Issuing, installing and updating just one cert across web servers is far simpler than tracking many.
The flexibility to add or change the secured domain names without reissuing certification makes SANs ideal for dynamic IT environments.
Centralized Key Management
A SAN certificate uses one public/private key pair which empowers greater oversight into encryption practices across associated domains, reducing the risk of expired or vulnerable keys falling through the cracks.
Simplified Certificate Renewal
When renewal time comes around, you only have one SSL/TLS certificate requiring updates across all your infrastructure instead of reissuing certs for each individual domain.
Ideal for Load Balancers & CDNs
Applications like cloud-based load balancers and content delivery networks serving traffic for multiple web properties can truly maximize ROI using one SAN certificate.
Smoother Mergers & Migrations
As companies grow via acquisitions or joint ventures, SANs provide must-have flexibility to quickly consolidate freshly acquired domains under existing security certs.
Mix and Match Domains
A major advantage over wildcard certificates is that SANs allow freely mixing top-level and subdomains across various segments of your business, regardless of domain structure.
In summary, embracing SAN certificates unlocks simplicity and versatility benefits in terms of cost, security, operations, and technology infrastructure scalability.
Distinguishing SAN Certificates from Other Options
With the value of SAN certs clear, how do they differ from alternatives like wildcard and Unified Communications certificates?
Wildcard Certificates also secure unlimited subdomains, but only under the base domain, not mixing across TLDs. Renewal and revocation are tied together across all subdomains.
Unified Communications Certs (UCC) allow bundling together a mix of domain types like those found in Exchange/OCS deployments. But they may not encompass public web domains, and lack some of the flexible consolidation capabilities made possible by true Subject Alternative Name certificates.
In contrast, the independent domain entries bundled into a SAN certificate provide utilization benefits surpassing either alternative in many standard web server scenarios.
Step-by-Step Guide to Generate a SAN CSR with OpenSSL
Okay, time for the fun stuff! Let‘s walk through creating your own SAN certificate signing request using OpenSSL…
OpenSSL is an open-source toolkit for working with SSL/TLS from the command line, providing full support for SAN certificates. We‘ll utilize it to generate a CSR file to submit to your preferred certificate authority.
Prepping Your OpenSSL Environment
You‘ll want to install OpenSSL 1.0.2 or higher on whatever server will store your private key and have the certificate installed later – typically a load balancer, reverse proxy, or web server.
Most Linux distros have OpenSSL in their package managers:
$ sudo apt install openssl # Debian/Ubuntu
$ sudo yum install openssl # RHEL/CentOS
$ sudo dnf install openssl # Fedora For MacOS, OpenSSL comes pre-installed or easily available via Homebrew. On Windows, grab a binary here.
To confirm your OpenSSL version:
$ openssl version
OpenSSL 1.1.1f 31 Mar 2020Once setup, let‘s start making some SSL magic!
Configuring Your SAN Details
We‘ll specify our desired SAN certificate contents within a basic text configuration file.
Copy this template to san_options.cnf and customize your details:
[ req ]
default_bits = 2048 // Key size
distinguished_name = req_distinguished_name
req_extensions = req_ext
[ req_distinguished_name ]
countryName = US
stateOrProvinceName = YourState
localityName = YourCity
organizationName = YourCompany
commonName = yourcompany.com
[ req_ext ]
subjectAltName = @alt_names
[alt_names] // Your SAN subdomains
DNS.1 = yourcompany.com
DNS.2 = yourbrand.com
DNS.3 = yourotherdomain.comBe sure to update fields like organization details along with the target domains you want protected by the certificate. The commonName field should match the primary domain.
Generating the CSR (Certificate Signing Request)
Next, use that config file while invoking OpenSSL to produce your actual CSR payload containing all the key data:
$ openssl req -out san_csr.pem -newkey rsa:2048 -nodes -keyout san_key.pem -config san_options.cnfThis will generate two files:
san_csr.pem – The certificate signing request to be submitted to a trusted CA for signing
san_key.pem – The private key for decrypting HTTPS traffic sent to your domains later
Keep this private key confidential for production use!
Verifying SAN Contents in CSR
Before sending your CSR off to be signed, validate that it properly encapsulates the Subject Alternative Name domains you specified:
$ openssl req -text -noout -in san_csr.pem | grep DNS
DNS:yourcompany.com, DNS:yourbrand.com, DNS:yourotherdomain.com Excellent – all target domains are present! Our multi-domain CSR is complete and ready for certification.
Issuing Your Signed SAN Certificate
Finally, take that slick CSR and request your SSL/TLS certificate from your chosen certificate authority. They will first verify your organization details and domain ownership rights.
As long as all checks pass, they will cryptographically sign the CSR contents using their private CA key and issue the final certificate bundle for use in protecting communication to the included domains.
I recommend reputable CAs like DigiCert, GlobalSign, or Sectigo who fully accommodate SAN CSRs.
Be sure to request 1-2 years of validity to save hassle compared to shorter certificate lifespans.
Once issued, take that shiny new cert (with bundled intermediate and root certificates) and install it alongside your private key to complete the SAN SSL setup process!
Managing Your SAN Certificates
Okay, your multi-domain certificate is setup and working beautifully! But we‘re not quite done yet – proper management keeps your SAN certificate resilient and hassle-free. Here are pointers for ongoing operations:
Distributing Your Certificate
For maximum value from multi-domain capabilities, distribute copies of certificates and private keys across backend servers like load balancers and front-end web proxies.
Utilizing a central private key store helps securely syncSSL assets among components. Orchestrators like Kubernetes offer baked-in secret distribution capabilities.
Regular Renewals
Set calendar reminders ahead of SAN certificate expiration so you reissue a fresh certificate from your CA at most once per year without any disruption.
Consider Revocation Scenarios
If your CA offers certificate revocation capabilities, have a plan for emergency domain removal from a SAN cert in case the private key is compromised. Otherwise, be prepared to request a brand new replacement certificate.
Investigate Certificate Lifecycle Automation
For enterprises, specialized PKI solutions exist to orchestrate certificate lifecycles end-to-end across domains and devices, bringing simplicity to even the most complex infrastructures.
Strictly Protect Private Key Access
With one private key securing multiple domains, restricting access is paramount. Never share private keys publicly! Enable key backup protections but limit accessibility.
Following these best practices will keep your multi-domain certificates running smoothly for years of encrypted services joy!
Convenience and Flexibility – Now and In the Future
As you can see, Subject Alternative Name certificates unlock tremendous simplicity benefits compared to juggling many single-domain certs for all your web presences.
Whether managing networks on-premise or scaling across multi-cloud environments, SANs deliver a versatile way to consolidated domains under one manageable certificate.
New encryption algorithms and security protocols surely lie ahead across the web landscape. But the core protections and risk reduction enabled by SSL/TLS certificates will continue playing a pivotal role securing websites, devices and communications channels into the future.
And whatever shape the web takes years down the road, I believe adaptable multi-domain certificates will remain vital tools for establishing versatile trust and security tailored to organizational needs. SAN certificates herd domains together, thereby simplifying encryption across the board.
So simplify your life – go forth and conquer website security the SAN way! Your IT department and future self will thank you later.
Let me know if any questions come up along your certificate journey!
