Export Cert for Backup/Migration & Understanding How to Get SANs on Your Certificate

Follow SSLREPO latest news

Export Cert for Backup/Migration & Understanding How to Get SANs on Your Certificate

Managing SSL/TLS certificates involves various tasks beyond simple installation. You might need to Export Cert – typically including its private key into a PFX file – for crucial operations like server backups, migrations, or load balancing setups. Separately, you might realize your current SSL certificate only covers one domain (e.g., www.yourdomain.com), but you also need to secure other hostnames like yourdomain.com or mail.yourdomain.com. This leads to the question: can you add san to certificate? (SAN stands for Subject Alternative Name).

While exporting an existing certificate is straightforward, adding SANs to an already issued certificate isn’t possible due to the immutable nature of digital certificates. Instead, you need to obtain a new certificate that includes the desired SANs from the outset.

This guide clarifies both processes: how to securely export existing certificates on Windows and the correct procedure for obtaining a new certificate with the Subject Alternative Names you require, using services from providers like sslrepo.com.

Key Takeaways

  • Exporting Certificates (PFX): Necessary for backups, server moves, or deploying the same certificate/key on multiple servers (load balancing). Usually done via MMC on Windows, creating a password-protected PFX file containing the certificate(s) and private key.
  • What are SANs?: Subject Alternative Names allow a single SSL certificate to secure multiple different hostnames (domains or subdomains). Certificates with SANs are often called Multi-Domain or UCC certificates.
  • Cannot Modify Issued Certificates: You cannot directly add san to certificate after it has been issued by a Certificate Authority (CA). Certificates are cryptographically signed and immutable.
  • The Correct Process for SANs: To get a certificate covering multiple hostnames, you must:
    1. Identify all required hostnames.
    2. Generate a new Certificate Signing Request (CSR) that explicitly includes all desired SANs.
    3. Purchase or reissue a Multi-Domain (SAN/UCC) certificate using the new CSR.
  • Security is Paramount: Exported PFX files containing private keys must be stored with extreme security.

Why and How to Export Cert (as PFX on Windows)

As covered previously, exporting a certificate with its private key is vital for:

  • Backups: Ensuring you can restore HTTPS functionality after server failure.
  • Migrations: Moving a website and its security context to a new server.
  • Load Balancing: Installing the same identity on multiple servers.

Standard Method (Windows MMC):

  1. Open MMC (mmc.exe).
  2. Add the Certificates snap-in for the Computer account (Local computer).
  3. Navigate to Personal > Certificates.
  4. Right-click the desired certificate -> All Tasks > Export….
  5. Follow the wizard, crucially selecting “Yes, export the private key”. (If greyed out, the key isn’t exportable or present).
  6. Choose the PKCS #12 (.PFX) format, include the certificate path if possible.
  7. Set a strong password to protect the PFX file.
  8. Save the .pfx file to a secure location.

This exported PFX file contains everything needed to install the certificate and key on another Windows machine.

Understanding SAN (Subject Alternative Name) Certificates

A standard SSL certificate typically secures only one specific hostname (the Common Name, e.g., www.yourdomain.com). What if you need to secure more?

  • Wildcard Certificates: Secure one domain and unlimited subdomains at a single level (e.g., *.yourdomain.com covers www, mail, shop, etc.). They don’t cover the root domain (yourdomain.com) automatically (though some CAs add it) or different domains.
  • SAN (Multi-Domain/UCC) Certificates: This is the flexible solution. A single SAN certificate can protect multiple, different hostnames. These names are listed in the “Subject Alternative Name” extension within the certificate. Examples include:
    • www.yourdomain.com (as Common Name)
    • yourdomain.com (as SAN)
    • mail.yourdomain.com (as SAN)
    • shop.anotherdomain.net (as SAN)
    • autodiscover.yourdomain.com (as SAN)

SAN certificates are ideal for securing different variations of your domain, different subdomains, or even completely different domain names under one certificate, simplifying management.

The Critical Point: You Cannot Add SANs to an Existing Certificate

Once a CA issues an SSL certificate, its contents are cryptographically signed and sealed. You cannot alter it – not the Common Name, not the expiration date, and you cannot add new SANs to it.

Attempting to “add” SANs requires replacing the certificate entirely.

The Correct Process: Getting a Certificate With SANs

If you need to secure additional hostnames currently not covered by your certificate, follow these steps:

  1. Identify ALL Required Hostnames: List every single hostname (subdomain or different domain) you need the new certificate to secure. Include the primary domain (which will be the Common Name) and all others that will be SANs.
  2. Generate a NEW Certificate Signing Request (CSR) Specifying SANs: This is the crucial step. The CSR itself must include the SAN information. How you do this depends on the tool:
    • IIS Manager (Basic Wizard): The standard “Create Certificate Request” wizard in IIS does not have a straightforward field to add SANs.
    • certreq.exe (Windows Command Line): You can use the certreq command with a custom .inf file that includes a [RequestAttributes] or [Extensions] section specifying the SANs. Example snippet for an .inf file:
      inf [Extensions] 2.5.29.17 = "{text}" _continue_ = "dns=yourdomain.com&" _continue_ = "dns=mail.yourdomain.com&" _continue_ = "dns=autodiscover.yourdomain.com"
    • OpenSSL (Common on Linux/macOS, available for Windows): You typically use a configuration file (.cnf) with the openssl req command, specifying SANs under the [alt_names] section referenced in the config. Example snippet for a .cnf file:
      ini

[req]

req_extensions = v3_req …

[v3_req]

subjectAltName = @alt_names …

[alt_names]

DNS.1 = yourdomain.com DNS.2 = mail.yourdomain.com DNS.3 = autodiscover.yourdomain.com Hosting Panels/Online Tools: Some web-based tools or hosting panels might provide specific fields to enter SANs during CSR generation. Obtain a Multi-Domain (SAN/UCC) Certificate:

  • Purchase: Buy a new Multi-Domain (SAN/UCC) certificate from a trusted provider like sslrepo.com, submitting your new CSR (containing the SANs) during the order process. Specify the number of SANs you need.
  • Reissue: If your current certificate is relatively new and your provider allows it, you might be able to reissue the certificate. This usually involves generating the new CSR with SANs and going through the CA’s reissue process (often free within a certain timeframe or for a fee). Check your provider’s policy.

Validate: The CA will need to validate control over all domains/hostnames listed in the CSR (Common Name and all SANs). Install the New Certificate: Once issued, install the new certificate (which now includes the SANs) on your server(s), replacing the old one. (Optional) Export the New Certificate: If needed for backup or migration, you can now Export Cert (the new one with SANs) as a PFX file using the MMC method described earlier.

Secure Storage Reminder

Whether it’s an exported backup of an old certificate or the newly exported PFX of your SAN certificate, remember the best practices for Storing certificates: use secure, access-controlled locations (not web servers), strong passwords stored separately (password manager/vault), encryption, and maintain a clear inventory.

Conclusion

While you can easily Export Cert (as PFX) for backup or migration, modifying an issued certificate to add san to certificate is not possible. The correct approach is to plan ahead, identify all hostnames you need to secure, generate a new CSR that includes these names as Subject Alternative Names, and then purchase or reissue a Multi-Domain (SAN/UCC) certificate using that new CSR. Understanding this distinction is key to efficient and effective SSL management.

Need a flexible certificate to secure multiple hostnames? Explore Multi-Domain (SAN/UCC) SSL options at sslrepo.com.

Frequently Asked Questions (FAQ)

Q1: Can I add just one more domain name to my current SSL certificate?
A: No, you cannot modify an already issued SSL certificate. You need to get a new certificate (either by purchasing a Multi-Domain/SAN certificate or reissuing your existing one if supported) that includes the new domain name in the Subject Alternative Name field, based on a new CSR.

Q2: How do I create a CSR that includes SANs on Windows?
A: The basic IIS Manager wizard doesn’t support this easily. You typically need to use the command-line tool certreq.exe with a custom .inf configuration file specifying the SANs, or use OpenSSL for Windows with a configuration file.

Q3: What’s the difference between a Wildcard and a SAN certificate?
A: A Wildcard (*.domain.com) covers unlimited subdomains at one specific level of a single domain. A SAN certificate can cover multiple completely different domain names and/or specific subdomains across different domains (e.g., www.site1.com, mail.site1.com, www.site2.org).

Q4: Is exporting a certificate the same as backing it up?
A: Exporting the certificate with its private key into a PFX file is a common way to create a backup that can be used to restore the certificate and key on the same or another server.

Q5: If I reissue my certificate to add SANs, do I need to generate a new CSR?
A: Yes, almost certainly. The CA needs a new CSR that contains the requested SANs to issue the new certificate correctly.

Q6: Where should I store the PFX file after I export the certificate?
A: Store it in a highly secure, access-controlled location – NOT on the web server itself. Use encrypted storage, a secure file share, or a secrets management system. Protect the PFX password using a password manager.

Scroll to Top