How to install an SSL certificate

Every browser connection to your website starts with a handshake. The browser sends a request, your server responds with a certificate, and the two negotiate an encrypted channel before any data moves. If that certificate is missing, expired, or misconfigured, visitors see a warning page instead of your site. Search engines penalize the ranking. Payment processors refuse to process transactions. What should be invisible infrastructure becomes a visible problem.

SSL certificates are one of those things that most site owners never think about until something breaks. This guide covers what SSL certificates actually are, how they work at a technical level, how they are managed in a modern hosting environment, and how to install a custom certificate when the default automatic option is not enough.

What an SSL certificate actually does

An SSL certificate serves two purposes: encryption and identity verification.

Encryption. When a browser connects to your server over HTTPS, the certificate enables TLS (Transport Layer Security) to encrypt all data exchanged between the browser and the server. Without it, everything travels in plaintext – login credentials, form submissions, payment details, session cookies. Anyone on the network path (a compromised router, a malicious Wi-Fi hotspot, an ISP) can read and modify that traffic.

Identity verification. The certificate proves that the server responding to the browser is actually the server for the domain the visitor typed in. A certificate for example.com is issued by a Certificate Authority (CA) that has verified the domain owner controls that domain. When the browser receives the certificate, it checks the CA’s signature against its built-in list of trusted CAs. If the signature checks out and the domain matches, the browser trusts the connection. If anything fails, the browser shows a security warning.

The term “SSL” is technically outdated – SSL (Secure Sockets Layer) was replaced by TLS over two decades ago – but the industry still uses “SSL certificate” to refer to the X.509 certificates used by TLS. The certificate itself is the same regardless of whether you call it SSL or TLS.

How TLS works (the short version)

Understanding the TLS handshake helps when troubleshooting certificate issues.

1. Client Hello. The browser sends a message to the server listing the TLS versions and cipher suites it supports.
2. Server Hello. The server picks a TLS version and cipher suite, then sends its certificate.
3. Certificate verification. The browser checks the certificate’s validity: is it signed by a trusted CA? Does the domain name match? Has it expired? Is it on a revocation list?
4. Key exchange. The browser and server negotiate a shared session key using asymmetric encryption (the certificate’s public key). This is the computationally expensive part.
5. Encrypted session. Both sides switch to symmetric encryption using the session key. All subsequent data is encrypted.

This entire process takes milliseconds on modern hardware. TLS 1.3 reduced the handshake to a single round trip, and session resumption can make repeat connections even faster.

Types of SSL certificates

Not all certificates are the same. They differ in what they validate and how many domains they cover.

Validation levels

Domain Validated (DV). The CA verifies that you control the domain, usually by checking a DNS record or serving a file at a specific URL. DV certificates are issued in minutes and are what Let’s Encrypt provides for free. For most websites, DV is sufficient.

Organization Validated (OV). The CA verifies the domain and the legal identity of the organization that owns it. This requires submitting business documentation and typically takes one to three days. OV certificates display the organization name in the certificate details, but modern browsers no longer show this prominently.

Extended Validation (EV). The most thorough validation level. The CA verifies the legal, physical, and operational existence of the organization. EV certificates used to display the company name in a green address bar, but most browsers have removed this visual distinction. The practical security difference between EV and DV is debatable – the encryption is identical, and phishing sites have been obtained with EV certificates.

Coverage types

Single domain. Covers exactly one fully qualified domain name (FQDN), like example.com . Does not cover www.example.com unless explicitly included as a Subject Alternative Name (SAN).

Wildcard. Covers a domain and all its single-level subdomains. A wildcard certificate for *.example.com covers www.example.com , shop.example.com , and api.example.com , but not example.com itself (the bare domain) unless also listed as a SAN. It also does not cover multi-level subdomains like dev.api.example.com .

Multi-domain (SAN). Covers multiple unrelated domains listed as Subject Alternative Names. A single certificate can cover example.com , example.org , and anotherdomain.net . Useful when you run multiple sites on the same server.

Automatic SSL with Let's Encrypt

Let’s Encrypt is a free, automated Certificate Authority that has fundamentally changed how SSL works for most websites. Before Let’s Encrypt launched in 2015, every certificate cost money and required manual installation. Today, the majority of websites use automatically provisioned DV certificates.

How automatic provisioning works

When you add a website to a hosting platform that supports automatic SSL, the process typically works like this:

1. The server requests a certificate from Let’s Encrypt for your domain
2. Let’s Encrypt issues an HTTP-01 challenge – it asks the server to serve a specific token at  http://yourdomain.com/.well-known/acme-challenge/<token>
3. The server places the token at that path
4. Let’s Encrypt fetches the token from the public internet, confirming the server controls the domain
5. Let’s Encrypt issues a certificate valid for 90 days
6. The server installs the certificate and configures the web server to use it
7. A renewal process runs periodically to replace the certificate before it expires

The 90-day validity period is intentional. Short-lived certificates reduce the damage window if a private key is compromised, and automation makes frequent renewal painless.

How it works on Hostney

When you create a website on Hostney, the system automatically provisions a Let’s Encrypt certificate for your subdomain. There is nothing to configure, no DNS records to add (assuming your domain already points to the server), and no renewal to manage. The certificate covers the exact FQDN of your subdomain.

The provisioning happens through Certbot using the webroot plugin. The server places the ACME challenge token in the web root, Let’s Encrypt validates it, and the certificate files land in /etc/letsencrypt/live/<your-domain>/ . Nginx is configured to use these files automatically.

Renewal runs on a timer. When a certificate is within 30 days of expiring, Certbot renews it automatically and reloads the web server configuration. You do not need to monitor expiration dates or take any manual action.

The SSL status of every subdomain is monitored. A background process checks certificate presence and expiration dates across all servers, updating the control panel so you can see at a glance whether each site has a valid certificate.

When automatic SSL is not enough

Let’s Encrypt works perfectly for the vast majority of websites. But there are cases where you need a different certificate:

• Organization or Extended Validation. If your organization requires OV or EV certificates for compliance, branding, or contractual reasons, you need to purchase and install one from a commercial CA.
• Wildcard from a commercial CA. While Let’s Encrypt does issue wildcard certificates, they require DNS-01 validation which is not always compatible with every DNS setup. Some organizations prefer commercial wildcards for operational reasons.
• Multi-domain certificates. If you need a single certificate covering multiple unrelated domains.
• Longer validity periods. Let’s Encrypt certificates are valid for 90 days. Some environments prefer one-year certificates to reduce renewal frequency (though this is increasingly rare as automation improves).
• Specific CA requirements. Some industries or partners require certificates from a specific Certificate Authority.

In these cases, you install a custom certificate.

How to get an SSL certificate

If you need a certificate beyond what Let’s Encrypt provides, you purchase one from a commercial Certificate Authority. The process involves three steps.

Step 1: Generate a CSR (Certificate Signing Request)

A CSR is a block of encoded text that contains your public key and the domain information the certificate should cover. You generate it on the server or your local machine using OpenSSL:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout yourdomain.key \
  -out yourdomain.csr

This generates two files:

• yourdomain.key  – your private key. Guard this carefully. Anyone with this file can impersonate your server.
• yourdomain.csr  – the CSR you submit to the CA.

During generation, OpenSSL asks for several fields:

• Common Name (CN): Your fully qualified domain name (e.g.,  www.example.com  or  *.example.com  for a wildcard)
• Organization: Your company name (for OV/EV certificates)
• Country, State, Locality: Your organization’s location
• Email: Contact email

For DV certificates, only the Common Name matters. The CA ignores the other fields.

If you want a certificate covering multiple domains, you need to include Subject Alternative Names. This requires an OpenSSL configuration file:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout yourdomain.key \
  -out yourdomain.csr \
  -config <(cat <<EOF

[req]

default_bits = 2048 prompt = no distinguished_name = dn req_extensions = san

[dn]

CN = example.com

[san]

subjectAltName = DNS:example.com,DNS:www.example.com,DNS:shop.example.com EOF )

Step 2: Submit the CSR to a Certificate Authority

Purchase a certificate from a CA (DigiCert, Sectigo, GlobalSign, GoDaddy, etc.) and submit your CSR during the order process. The CA will validate your domain ownership through one of these methods:

• HTTP validation: Place a specific file at a URL on your domain
• DNS validation: Create a CNAME or TXT record in your domain’s DNS
• Email validation: Respond to an email sent to an administrative address at your domain (admin@, webmaster@, etc.)

After validation, the CA issues your certificate, usually as a set of files:

• The certificate file (your domain’s certificate, PEM format)
• The CA bundle / intermediate certificates (the chain linking your certificate to the CA’s root)
• Sometimes a root certificate (usually not needed as browsers already trust it)

Step 3: Prepare your files

Before installation, you need three things in PEM format:

The certificate. This is your domain’s certificate. It starts with -----BEGIN CERTIFICATE----- and ends with -----END CERTIFICATE----- .

The private key. The key you generated in step 1. It starts with -----BEGIN PRIVATE KEY----- (or -----BEGIN RSA PRIVATE KEY----- for older formats). The key must be unencrypted – if you set a passphrase during generation, you need to remove it:

openssl rsa -in encrypted.key -out decrypted.key

Password-protected private keys cannot be used with most web servers because the server would need the password every time it starts, which breaks automated restarts and reloads.

The certificate chain (intermediate certificates). This is the sequence of intermediate CA certificates that link your certificate to a trusted root. Without the chain, some browsers and devices will show a certificate warning even though the certificate itself is valid. The chain is sometimes called the “CA bundle.”

Your CA typically provides the chain as a separate file, or as part of a “full chain” file. If you received multiple intermediate certificate files, concatenate them in order from your certificate’s issuer up to (but not including) the root:

cat intermediate1.pem intermediate2.pem > chain.pem

Installing a custom SSL certificate on Hostney

Once you have your certificate, private key, and chain, installing them through the Hostney control panel is straightforward.

Navigate to SSL certificates

1. Log into the Hostney control panel
2. Select your domain from the domain selector
3. Navigate to SSL certificates in the sidebar

Upload your certificate

The upload form is a three-step wizard:

Step 1: Select subdomain and paste certificate. Choose the subdomain this certificate is for from the dropdown. Then paste your certificate in PEM format into the certificate field. This is the content of your certificate file – everything from -----BEGIN CERTIFICATE----- through -----END CERTIFICATE----- .

Step 2: Paste your private key. Paste the private key in PEM format. It must be unencrypted (no password protection). The system will reject encrypted private keys.

Step 3: Add the certificate chain (optional). If your CA provided intermediate certificates, paste them here. While this step is marked optional, providing the chain is strongly recommended. Without it, the certificate may not be trusted by all browsers and devices.

Click Upload certificate to submit.

What happens after upload

When you upload a certificate, the system:

1. Validates the certificate. It checks that the certificate is in PEM format, is not self-signed, is not expired, and matches the selected subdomain (either an exact FQDN match or a wildcard match).
2. Validates the private key. It confirms the key is unencrypted and matches the certificate’s public key.
3. Stores the certificate. The certificate, private key, and chain are stored and deployed to the server hosting your subdomain.
4. Reconfigures the web server. The server’s nginx configuration is regenerated to use your imported certificate instead of the Let’s Encrypt certificate. Nginx is reloaded to pick up the new certificate.

The imported certificate takes priority over any existing Let’s Encrypt certificate. The Let’s Encrypt certificate is not deleted – it remains as a fallback. If you later delete your imported certificate, the system automatically falls back to the Let’s Encrypt certificate, so your site never loses SSL coverage.

Requirements for the upload

• Certificate must be in PEM format
• Private key must be unencrypted (no passphrase)
• Certificate cannot be self-signed
• Certificate must not be expired
• The certificate’s Common Name or Subject Alternative Names must match the subdomain’s FQDN (exact match or wildcard)
• Only one imported certificate per subdomain is allowed (uploading a new one replaces the existing import)

Viewing and managing certificates

After upload, your certificates appear in the SSL certificates list. Each certificate shows:

• The subdomain it covers
• Whether it is auto-generated (Let’s Encrypt) or imported (your custom certificate)
• The issuing CA
• The expiration date

You can view the certificate, private key, and chain for any certificate. For imported certificates, you can delete them to revert to the automatic Let’s Encrypt certificate.

Auto-generated Let’s Encrypt certificates cannot be deleted through the control panel. They are managed automatically by the system.

Understanding the certificate chain

The certificate chain is one of the most commonly misunderstood parts of SSL installation, and getting it wrong causes the most subtle issues.

When a browser receives your certificate, it needs to verify that a trusted authority issued it. But your certificate was not signed directly by a root CA that the browser trusts. Instead, it was signed by an intermediate CA, which was signed by another intermediate, which was eventually signed by a root CA. This sequence is the chain of trust.

Browsers and operating systems ship with a set of trusted root CA certificates. When they verify your certificate, they build the chain from your certificate up to a root they trust. If any intermediate certificate is missing, the chain breaks and the browser cannot verify your certificate.

Why chains matter in practice

Most desktop browsers are forgiving about incomplete chains. Chrome and Firefox can often find missing intermediates by following the Authority Information Access (AIA) extension in the certificate. They fetch the missing intermediate from the CA’s server and complete the chain.

But not all clients do this:

• Mobile browsers (especially older Android versions) are less likely to fetch missing intermediates
• curl, wget, and API clients typically do not follow AIA extensions and fail immediately
• Monitoring tools and uptime checkers may report certificate errors
• Other servers connecting to your API will reject the connection

This is why an SSL test might show your site as “A” rated in one tool while another reports chain issues. Desktop browsers hide the problem; everything else exposes it.

Testing your chain

After installing your certificate, verify the complete chain:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

Look for the certificate chain output. You should see your certificate, followed by one or more intermediates, ending near a root CA. If you see verify return:0 or Verify return code: 0 (ok) , the chain is complete.

You can also use online tools like SSL Labs’ SSL Server Test to get a detailed analysis of your certificate configuration, including chain completeness, protocol support, and cipher suite configuration.

Troubleshooting common SSL issues

Certificate does not match domain

The error “certificate does not match domain” or NET::ERR_CERT_COMMON_NAME_INVALID means the certificate’s Common Name and Subject Alternative Names do not include the domain the browser is trying to reach.

Common causes:

• You installed a certificate for  example.com  but visitors are accessing  www.example.com  (or vice versa)
• You have a wildcard certificate for  *.example.com  but are accessing the bare domain  example.com  (wildcards do not cover the bare domain unless it is listed as a SAN)
• The certificate was issued for a different domain entirely

Fix: check what domains your certificate covers by examining it:

openssl x509 -in certificate.pem -text -noout | grep -A1 "Subject Alternative Name"

Mixed content warnings

After enabling HTTPS, your site loads over HTTPS but some resources (images, scripts, stylesheets) are still loaded over HTTP. Browsers block or warn about this mixed content.

Fix: update all resource URLs to use HTTPS or protocol-relative URLs ( //example.com/path ). In WordPress, this often requires a search and replace across the database to update hardcoded HTTP URLs.

ERR_SSL_PROTOCOL_ERROR

This typically means the server is not responding with a valid TLS handshake. Causes include:

• The web server is not configured to listen on port 443
• The SSL configuration is invalid (wrong file paths, corrupt certificate files)
• A firewall is blocking port 443

Certificate expiration

Certificates have a fixed validity period. Let’s Encrypt certificates last 90 days, commercial certificates typically last one year. When a certificate expires, browsers show a full-page warning that most visitors will not click through.

If you are using the automatic Let’s Encrypt certificate on Hostney, renewal is handled for you. If you installed a custom certificate, you are responsible for replacing it before it expires. Set a calendar reminder for at least two weeks before the expiration date.

OCSP stapling

OCSP (Online Certificate Status Protocol) is how browsers check whether a certificate has been revoked. Without OCSP stapling, the browser makes a separate request to the CA’s OCSP responder during every TLS handshake, adding latency and creating a privacy leak (the CA knows which sites you visit).

OCSP stapling lets the server fetch the OCSP response itself and “staple” it to the TLS handshake. The browser gets the revocation status directly from your server without contacting the CA.

On Hostney, OCSP stapling is enabled automatically for Let’s Encrypt certificates. For imported certificates, OCSP stapling depends on whether the CA provides an OCSP responder URL in the certificate. Most commercial CAs do.

SSL and performance

A common concern is that HTTPS is slower than HTTP because of encryption overhead. This was measurably true a decade ago but is no longer a practical concern.

Modern CPUs have hardware AES acceleration that makes symmetric encryption essentially free. The TLS handshake adds latency to the first connection, but TLS 1.3 reduced this to a single round trip (down from two in TLS 1.2). Session resumption eliminates the handshake entirely for repeat visitors.

HTTPS actually enables performance features that HTTP cannot use:

• HTTP/2 requires HTTPS in all major browsers. HTTP/2 multiplexes multiple requests over a single connection, eliminates head-of-line blocking, and supports header compression, providing significant performance improvements over HTTP/1.1.
• HTTP/3 (QUIC) also requires HTTPS. It uses UDP instead of TCP, eliminating TCP’s head-of-line blocking at the transport layer and reducing connection setup time.

A site on HTTPS with HTTP/2 or HTTP/3 will almost always outperform the same site on plain HTTP/1.1.

SSL best practices

Always redirect HTTP to HTTPS. If your site is accessible over both HTTP and HTTPS, search engines may index both versions, splitting your page authority. Configure a permanent redirect (301) from HTTP to HTTPS for all URLs.

Use HSTS. HTTP Strict Transport Security tells browsers to always use HTTPS for your domain, even if the user types http:// . This prevents SSL stripping attacks where an attacker downgrades the connection to HTTP. The header looks like:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Keep your private key private. Never share your private key via email, paste it in a support ticket, or commit it to a Git repository. If the key is compromised, anyone can impersonate your server. Revoke the certificate and issue a new one immediately if the key leaks.

Monitor expiration dates. Automated certificates handle renewal, but custom certificates require manual replacement. A single expired certificate can take your site offline until someone notices and replaces it.

Test after installation. Always verify your certificate after installation. Check the chain, test from multiple devices, and use an SSL testing tool to catch issues before your visitors do.

Provide the full chain. Always include intermediate certificates. A certificate that works in Chrome on your laptop but fails on a customer’s Android phone is worse than no certificate at all because you will not discover the problem through your own testing.

Summary

SSL certificates encrypt the connection between browsers and your server, and verify your server’s identity. Modern hosting platforms provision and renew certificates automatically through Let’s Encrypt, which covers the needs of most websites.

When you need a certificate beyond what automatic provisioning offers – for organizational validation, wildcard coverage, or compliance requirements – the process is: generate a CSR, submit it to a Certificate Authority, receive your certificate files, and install them through your hosting control panel. On Hostney, this is a three-step upload wizard that validates your certificate and deploys it to the server automatically, with the existing Let’s Encrypt certificate remaining as a fallback.

The most common installation issues are incomplete certificate chains (always provide intermediates), domain name mismatches (verify what the certificate covers before installing), and forgetting to renew custom certificates before they expire. Test your installation from multiple clients, not just your desktop browser, to catch chain issues that forgiving browsers hide.

For the underlying DNS security that ensures visitors reach the right server in the first place, see What is DNSSEC and why does it matter for your website. And if you are migrating a site and need to handle SSL at the destination, the WordPress migration guide covers the SSL considerations during that process.