How to Install an SSL Certificate
Installing an SSL/TLS certificate means more than “getting the padlock”. Technically, you need to place a certificate and its private key on the server, configure your web server (such as Nginx or Apache) to serve that certificate for the right domain name, and make sure the certificate chain (intermediate CA bundle) is delivered correctly. If any of these pieces are wrong, browsers may show warnings, some clients will fail to connect, or HTTPS will work only for one hostname while others still error out.
Before you start, confirm that DNS is already pointing to the correct server and that the domain actually reaches your web service. If you are migrating to new infrastructure, the safest approach is to prepare HTTPS on the new server first, test it thoroughly, and only then switch DNS. In managed environments this is often automated; on a self-managed server you gain full control, but you must take responsibility for renewals, reloads, and security tuning.
On CloudHosting you can align the installation path with your service model: if you need a specific certificate type (DV/OV/EV, wildcard, or multi-domain), see SSL Certificates. If you want a simpler workflow where issuance and renewals are handled for typical websites, consider Hosting. If you need custom ports, multiple applications, reverse proxying, or deeper TLS control, you will typically choose Virtual Servers.
1) Choose the certificate type and issuance method
Most installations follow one of two paths. Path one: use Let’s Encrypt with an ACME client (for example, certbot) to automate issuance and renewals. Path two: obtain a certificate from a Certificate Authority (CA) and install it manually. In both cases the server needs a private key and certificate files, but with Let’s Encrypt the ACME client usually generates and manages them for you.
For a single domain and a couple of hostnames, a DV certificate is usually enough. If you must secure many subdomains, a wildcard certificate can be convenient, and it often requires DNS-01 validation (a temporary TXT record in DNS). If you need to cover several different domains, a SAN (multi-domain) certificate may fit better. Choosing correctly up front reduces future maintenance and avoids reissuing certificates as your architecture grows.
2) Prepare the server: ports, firewall rules, and virtual hosts
HTTPS normally uses TCP port 443. Make sure 443 is allowed through the firewall and that your web server is listening on the correct IP address. If you plan to use Let’s Encrypt HTTP-01 validation, port 80 must also be reachable (at least during issuance/renewal), because the CA fetches a verification file under /.well-known/acme-challenge/. If you cannot expose port 80, you can use DNS-01 validation instead, publishing a TXT record in DNS to prove domain control.
If multiple domains share one IP address, modern clients rely on SNI (Server Name Indication): the browser indicates which hostname it wants during the TLS handshake, and the server can present the correct certificate for that hostname. Very old clients without SNI may see the “wrong” certificate. If you have such legacy requirements, you might need a dedicated IP for the critical hostname or a compatibility-focused deployment plan.
3) Let’s Encrypt installation: a typical workflow
With Let’s Encrypt, the ACME client proves domain control and retrieves a certificate; then you either let the client adjust your web server configuration automatically, or you install it manually by pointing your server configuration to the certificate files. For simple setups, using certbot with an Nginx/Apache integration plugin can save time. For custom configurations, the safer approach is often “certonly”, where certbot obtains the certificate and you update the server config yourself.
certbot certonly --webroot -w /var/www/example.com -d example.com -d www.example.com certbot renew --dry-run
Know where the files are. Let’s Encrypt typically stores active files under /etc/letsencrypt/live/DOMAIN/. Web servers usually reference fullchain.pem (leaf certificate plus intermediate chain) and privkey.pem (the private key). When the certificate is renewed, these files are updated, but your web server may still need a reload to start using the new certificate. That is why renewal hooks (deploy hooks) or automated reload steps are an important part of a “finished” installation.
4) Manual installation: CSR, private key, and full chain
For commercial certificates, the process often starts by generating a CSR (Certificate Signing Request). The CSR contains your public key and the names you want to secure; the private key stays on your server and must never be shared. After validation, the CA issues the certificate and intermediate certificates that form a chain up to a trusted root. If the chain is incomplete on the server, some devices will fail even though the certificate itself is valid.
openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr openssl req -in example.com.csr -noout -text
After issuance, you typically receive a server certificate and a CA bundle (intermediate chain). Nginx often expects a single “fullchain” file containing the server certificate followed by intermediates in the correct order. Apache can accept either separate chain files or a combined chain, depending on configuration. If you are unsure, validate what your server is sending using openssl from a client perspective; it quickly reveals whether intermediates are missing.
5) Nginx configuration example
In Nginx, you normally create a server block on port 443, set server_name for the domain, and provide the certificate paths. Many deployments also enable HTTP/2, but the minimum for correctness is simply serving the right certificate for the right hostname. Adjust the paths to match your environment; with Let’s Encrypt, the files are commonly under /etc/letsencrypt/live/.
server {
listen 443 ssl http2;
server_name example.com www.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
root /var/www/example.com;
index index.php index.html;
}
Always test configuration syntax before reloading. Reload is usually safer than restart because it avoids dropping active connections. After a certificate renewal, a reload is often enough for Nginx to pick up updated files.
nginx -t systemctl reload nginx
6) Apache configuration example
With Apache, you typically enable TLS with mod_ssl and configure a VirtualHost on *:443. You set ServerName/ServerAlias and point to the certificate and key files. If you use a combined fullchain file, many setups work cleanly across clients. If you see errors, verify that the key matches the certificate and that the chain is complete.
ServerName example.com ServerAlias www.example.com SSLEngine on SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem DocumentRoot /var/www/example.com
After changes, run a configuration test and reload Apache. If Apache refuses to load the certificate, the most common causes are file permissions, mismatched key/cert pairs, or an incorrect path to the chain.
apachectl configtest systemctl reload apache2
7) Redirect HTTP to HTTPS and decide on a canonical hostname
A proper deployment ensures users always land on HTTPS. That usually means a port 80 configuration that redirects everything to HTTPS. It is also worth deciding whether your canonical address is with www or without, then redirecting the alternative to the canonical hostname. This reduces subtle SEO duplication, cookie scope confusion, and “works sometimes” reports from users who bookmark different variants.
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}
If you plan to enable HSTS, do it only after you are confident renewals are stable. HSTS instructs browsers to always use HTTPS for a period of time, and it can make mistakes “sticky”: if your certificate later expires, users may be blocked until you fix it. Roll out HSTS gradually with a small max-age, then increase it when the operational process is proven.
8) Mixed content: why the padlock can disappear
Even with a correct certificate, the browser may warn about mixed content if your HTTPS page loads some assets over HTTP (images, scripts, fonts, iframes). In that case the transport is encrypted, but part of the content is not, and browsers may block it. Fix mixed content by updating asset URLs to HTTPS, using relative URLs, and ensuring third-party resources support HTTPS. The fastest way to diagnose is the browser developer console, which lists blocked URLs.
9) Control panels (cPanel/ISPmanager/VestaCP): details still matter
If you use a hosting control panel, installation may be a few clicks: select the domain, paste certificate (PEM) and private key, or enable automatic Let’s Encrypt. Still, verify the essentials: the certificate is attached to the correct domain and aliases (www), the intermediate chain (CA bundle) is included, and the web server was reloaded after changes. Panels often have separate fields for “Certificate”, “Private Key”, and “CA Bundle”; leaving out the bundle is a classic cause of trust errors on certain devices.
Verification, Renewals, and Common Pitfalls
After installation, validate from multiple angles. Browsers show the user experience, but command-line tools show what the server actually presents: the certificate, the chain, and supported TLS versions. This matters especially during migrations or when multiple hostnames share one IP. A quick validation pass also catches “wrong vhost” problems where a certificate is installed but not actually used by the requested hostname.
openssl s_client -connect example.com:443 -servername example.com curl -I https://example.com
With Let’s Encrypt, reliability is mostly about automation. Confirm certbot renew works (dry-run) and ensure a reload happens after renewal. If renewal suddenly starts failing, common causes include: port 80 is no longer reachable, DNS now points elsewhere, the webroot path changed, or a reverse proxy blocks the ACME challenge. With DNS-01, failures are often caused by incorrect TXT values or slow DNS propagation.
When you see errors, classify them. “Name mismatch” means the certificate does not cover the hostname you are visiting. “Untrusted” often points to a missing intermediate chain. “Expired” points to renewal failure. “Wrong certificate” often indicates SNI/virtual host selection issues on port 443. Thinking in these categories speeds up troubleshooting dramatically.
A practical post-install checklist is: HTTPS loads with no warnings, the certificate covers all required hostnames, HTTP redirects to HTTPS, there is no mixed content, and renewals are automated and monitored. Once these are true, your SSL installation is operationally complete.