Preparing server certificates
Before you can serve HTTPS traffic, you need a public/private key pair and a certificate signed by a certificate authority (CA). The steps below use the openssl command-line tool, which ships with most Linux, BSD, and macOS systems.
Generate an RSA key pair
Start by generating a 2,048-bit RSA key pair. Shorter keys are vulnerable to brute-force attacks, while longer keys consume unnecessary CPU resources.
openssl genrsa -out www.example.com.key 2048
The command produces output similar to:
Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)
Create a certificate signing request
Next, embed your public key and organizational details into a certificate signing request (CSR). The openssl utility prompts you for the required metadata:
openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr
This produces:
You are about to be asked to enter information that will be incorporated
into your certificate request
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:California
Locality Name (for example, city) []:Mountain View
Organization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (for example, section) []:Webmaster Help Center Example
Team
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:[email protected]
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Verify the CSR is well-formed with:
openssl req -text -in www.example.com.csr -noout
The output should resemble:
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=CA, ST=California, L=Mountain View, O=Google, Inc.,
OU=Webmaster Help Center Example Team,
CN=www.example.com/[email protected]
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ad:fc:58:e0:da:f2:0b:73:51:93:29:a5:d3:9e:
f8:f1:14:13:64:cc:e0:bc:be:26:5d:04:e1:58:dc:
...
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha256WithRSAEncryption
5f:05:f3:71:d5:f7:b7:b6:dc:17:cc:88:03:b8:87:29:f6:87:
2f:7f:00:49:08:0a:20:41:0b:70:03:04:7d:94:af:69:3d:f4:
...
Obtain a signed certificate from a CA
Each certificate authority handles CSR submission differently: some provide a web form, others accept CSRs by email, and some resellers automate parts of the process entirely, including key generation. Submit your CSR to the CA of your choice and follow their instructions to receive your final certificate or certificate chain.
CAs charge varying amounts for vouching for your public key. Options exist for mapping one key to multiple DNS names, including several distinct names (such as example.com, www.example.com, and example.net) or wildcard names like *.example.com.
Once issued, copy the certificates to every front-end server, storing them in a location that is not web-accessible, such as /etc/ssl on Linux and Unix systems, or the directory IIS expects on Windows.
Configuring HTTPS service
With certificates installed, enable HTTPS on your servers without immediately redirecting HTTP traffic. Mozilla's server configuration generator provides reference configurations for most common web servers.
A key operational decision affects how you serve multiple hostnames:
- Assign a distinct IP address to each hostname your web server serves.
- Use name-based virtual hosting.
Distinct IP addresses let you support both HTTP and HTTPS seamlessly for all clients, but most operators prefer name-based virtual hosting to conserve IP addresses and simplify management. Each hostname or subdomain needs to be paired with its correct certificate.
Test your HTTPS setup regularly with Qualys' SSL Server Test and aim for a grade of A or A+. Treat any lower score as a bug to fix promptly—new attacks against algorithms and protocols appear continuously.
Making intrasite URLs protocol-agnostic
While your site runs on both HTTP and HTTPS, links within your site must work correctly regardless of which protocol a visitor uses. Use relative paths such as /jquery.js, or protocol-relative URLs that omit the protocol entirely, like //example.com/something.js.
Serving an HTTPS page that embeds HTTP resources triggers mixed content warnings, and some browsers refuse to load those insecure resources entirely. The reverse is safe: HTTP pages may include HTTPS resources without issue. For links to other pages on your site, relative URLs prevent HTTPS pages from linking back down to HTTP, which silently degrades the user's session.
Following good practices:
<h1>Welcome To Example.com</h1> <script src="https://web.dev/jquery.js"></script> <link rel="stylesheet" href="https://web.dev/assets/style.css"/> <img src="https://web.dev/images/logo.png"/>; <p>A <a href="https://web.dev/2014/12/24">new post on cats!</a></p>
Alternatively, use protocol-relative URLs:
<h1>Welcome To Example.com</h1> <script src="//example.com/jquery.js"></script> <link rel="stylesheet" href="//assets.example.com/style.css"/> <img src="//img.example.com/logo.png"/>; <p>A <a href="//example.com/2014/12/24/">new post on cats!</a></p>
For external links, serve them over HTTPS where the destination supports it:
<h1>Welcome To Example.com</h1> <script src="https://web.dev/jquery.js"></script> <link rel="stylesheet" href="https://web.dev/assets/style.css"/> <img src="https://web.dev/images/logo.png"/>; <p>A <a href="https://web.dev/2014/12/24">new post on cats!</a></p> <p>Check out this <a href="https://foo.com/"><b>other cool site.</b></a></p>
When your site depends on third-party resources such as CDNs or jquery.com, you have two reasonable options. Use protocol-relative URLs for those resources—most major providers already serve HTTPS. Or, better for control and security, host the resources yourself on a server you manage, which also removes reliance on a third party's uptime and integrity.
Large sites should consider protocol-relative URLs during the migration window. If you cannot yet guarantee HTTPS for every subresource, forcing the issue can break pages that still rely on HTTP. Plan for a transition period where both protocols remain fully functional, then lock in HTTPS once the migration is complete.
Signaling HTTPS to search engines
Place a canonical link at the head of each page so search engines index the HTTPS version of your content:
<link rel="canonical" href="https://…"/>
Update existing links with an automated script rather than by hand to avoid mistakes. Test against a development copy of your content, whether that content lives in a database or in static files, and push to production only after changes pass quality assurance. Tools such as Bram van Damme's mixed-content scanner can help identify insecure resources that remain on your pages.
Locking HTTPS in with HSTS and secure cookies
After setting up redirects, the next step is to make HTTPS the only viable connection option. Two mechanisms handle this: HTTP Strict Transport Security (HSTS) and the Secure flag on cookies.
HSTS tells clients to always connect via HTTPS, even when handed an http:// URL. This blocks attacks such as SSL Stripping and eliminates the round-trip cost of the 301 redirect used previously. You enable it by setting the Strict-Transport-Security header, and most web servers support adding this custom header. OWASP's HSTS page provides configuration links for various server software.
The Secure flag is equally critical for cookies used in authentication or session management. Without it, a cookie could be transmitted in plain text over HTTP, compromising the entire session even if all other security measures are in place. OWASP explains how to set the flag across common application frameworks; every framework has a supported method.
Search and performance considerations
Migrating to HTTPS doesn't hurt search rankings. Google treats HTTPS as a positive quality signal and publishes guidance on moving a site without losing rank. Bing offers similar guidelines for webmasters.
TLS overhead is normally minor when the content and application layers are properly optimized. For deep-dive advice on minimizing that cost, consult High Performance Browser Networking, Ivan Ristic's OpenSSL Cookbook and Bulletproof SSL And TLS, or Chris Palmer's talk on HTTPS and HTTP/2 performance. In some cases, TLS can even improve performance because it is a prerequisite for HTTP/2.
Referer headers and advertising
One side effect of HTTPS is that user agents suppress the Referer header when linking out to plain HTTP sites. Migrating the destination sites to HTTPS resolves this; you can then update your inbound links to use https:// or protocol-relative URLs. The Referrer Policy standard offers another workaround for various header-related issues.
Ad-supported sites face a particular stalemate: an HTTP <iframe> is treated as mixed content on an HTTPS page, so publishers can't show non-HTTPS ads without losing the security benefit, while advertisers have little reason to switch until publishers require it. To break the deadlock, favor advertisers that already serve over HTTPS and push the rest to make it an option. In the interim, you may need to postpone making all intra-site URLs relative until ad providers catch up.
