SSL certificates explained: HTTPS, certificate types and renewal

An SSL certificate lets a browser connect to your site over HTTPS, which encrypts the traffic between visitor and server and proves that the site is the one the address claims. Browsers trust only certificates issued by a recognized certificate authority, so a public website needs a trusted certificate. A self-signed one encrypts the connection too, but it triggers a warning. Certificates expire and must be renewed, and after you switch to HTTPS you also need to fix any page that still loads files over plain HTTP.

#What SSL, TLS and HTTPS actually do

SSL is the old name. The protocol in use today is TLS, but the name SSL certificate stuck as the everyday term. When a browser opens an HTTPS address, it agrees on encryption keys with the server, and the server presents its certificate. The certificate ties the domain name to a public key and is signed by a certificate authority (CA) that the browser already trusts.

That gives you three things:

• Encryption. Passwords, cookies, form data and payment details cannot be read by anyone on the network between the visitor and the server, such as the operator of a public Wi-Fi network.
• Integrity. Nobody along the way can change the page, insert ads or swap a download.
• Authentication. The browser checks that the certificate matches the domain in the address bar.

HTTPS does not make the site itself secure. An outdated plugin, a weak admin password or a vulnerable form is just as exploitable over an encrypted connection. HTTPS is the baseline: browsers mark plain HTTP pages as not secure, several browser features such as geolocation work only over HTTPS, and payment providers expect it on checkout and login pages.

#Self-signed and trusted certificates

A self-signed certificate is signed by the server itself instead of a CA. The encryption is the same, but the browser has no way to confirm who issued it, so it shows a full-page warning that the connection is not private and advises the visitor to go back. Most visitors leave at that point. Self-signed certificates are fine for internal tools, testing and staging, where the people using them know why the warning appears. A public site needs a trusted certificate.

	Self-signed	Trusted
Who signs it	The server itself	A certificate authority that browsers trust
Encryption	Yes	Yes
What visitors see	A full-page security warning	The page, with the usual padlock or site information icon
Good for	Testing, staging, internal tools	Any public website or shop

#Domain validation, single-name and wildcard certificates

Before a CA issues a certificate, it checks that you control the domain. For a domain-validated (DV) certificate that check is technical: you add a DNS record, place a file at a given address on the site, or answer an email sent to an admin address on the domain. DV certificates are the common choice for websites and online shops, and browsers show them the same way as any other trusted certificate. Organization-validated (OV) and extended-validation (EV) certificates add checks on the company behind the site. Browsers no longer mark them differently in the address bar, so for most sites they add paperwork without a visible difference.

The second choice is how many names the certificate covers.

• A single-name certificate covers one host name, such as www.example.com. Many CAs add the bare domain automatically, but check what the order says.
• A wildcard certificate covers every subdomain at one level, such as shop.example.com and blog.example.com under *.example.com. It does not cover a deeper level such as test.shop.example.com.
• A multi-domain certificate lists several specific names, which suits a few unrelated domains on one server.

Choose a wildcard when you run or plan several subdomains and do not want a separate certificate for each. For one site on one address, a single-name certificate is enough.

#Renewal and expiry

Every certificate has an end date. Once it passes, browsers show the same kind of full-page warning as for a self-signed certificate, and for most visitors the site is effectively down. Maximum certificate lifetimes have been getting shorter over the years, which makes manual renewal a growing risk.

• Know where each certificate comes from and when it expires. Browsers show the dates in the certificate details.
• Automate renewal where your host or CA supports it, and after the first automatic renewal, check that it actually worked.
• Send expiry notices to a shared address, not to one person's inbox.
• Remember every place the certificate is installed. The web server, a load balancer, a mail server or a CDN may each need the new one.

A certificate is issued for a domain, so it also depends on the domain staying registered. Domain names explained covers renewal, DNS and ownership, including the DNS records a CA may ask you to add for validation.

#Fixing mixed content after switching to HTTPS

Mixed content means an HTTPS page loads some resources over plain HTTP: an image, a script, a stylesheet, a font or an embedded video. Browsers block insecure scripts and stylesheets, and they try to load insecure images over HTTPS or flag them. The result can be a page that loses its layout, a feature that stops working, or a padlock that disappears.

The usual causes are absolute http:// links stored in the database, URLs hard-coded in the theme, and third-party embeds. A clean switch follows a short sequence:

1. Install the trusted certificate and confirm that the site opens over https:// without warnings.
2. Change the site address in the CMS settings to https://. In WordPress these are the WordPress Address and Site Address fields.
3. Take a backup, then replace stored http:// links to your own domain in the database with a search-and-replace tool that handles serialized data.
4. Fix URLs hard-coded in the theme and custom code, and switch third-party embeds to their HTTPS versions.
5. Open the browser's developer console on key pages. Mixed-content warnings list each offending URL.
6. Redirect all HTTP requests to HTTPS with a permanent (301) redirect, and update the site address in your analytics and search engine tools.

Once everything loads over HTTPS without errors, consider HSTS, a response header that tells browsers to use only HTTPS for your domain from then on. Turn it on only when you are sure every subdomain works over HTTPS, because browsers remember it.

#How PN Scripts can help

Every shared plan on PN Scripts Hosting includes self-signed SSL certificates, which are enough for testing. For a public site you can add a trusted certificate on the order form: a standard certificate for one host name or a wildcard certificate for the subdomains of a domain, each sold for one year. The SSL certificates page describes both options.