This page provides guidance for setting up HTTPS on your servers, including thefollowing steps:
- Creating a 2048-bit RSA public/private key pair.
- Generating a certificate signing request (CSR) that embeds your public key.
- Sharing your CSR with your Certificate Authority (CA) to receive a finalcertificate or a certificate chain.
- Installing your final certificate in a non-web-accessible place such as
/etc/ssl(Linux and Unix) or wherever IIS requires it (Windows).
Generate keys and certificate signing requests
This section uses the openssl command-line program, which comes with mostLinux, BSD, and Mac OS X systems, to generate private and public keys and a CSR.
Generate a public/private key pair
To start, generate a 2,048-bit RSA key pair. A shorter key can be broken bybrute-force guessing attacks, and longer keys use unnecessary resources.
Use the following command to generate an RSA key pair:
openssl genrsa -out www.example.com.key 2048This gives the following output:
Generating RSA private key, 2048 bit long modulus.+++.......................................................................................+++e is 65537 (0x10001)Generate a certificate signing request
In this step, you embed your public key and information about your organizationand your website into a certificate signing request or CSR. The opensslcommand asks you for the required metadata.
Running the following command:
openssl req -new -sha256 -key www.example.com.key -out www.example.com.csrOutputs the following:
You are about to be asked to enter information that will be incorporatedinto your certificate requestWhat 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 blankFor some fields there will be a default value,If you enter '.', the field will be left blank.-----Country Name (2 letter code) [AU]:CAState or Province Name (full name) [Some-State]:CaliforniaLocality Name (for example, city) []:Mountain ViewOrganization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.Organizational Unit Name (for example, section) []:Webmaster Help Center ExampleTeamCommon Name (e.g. server FQDN or YOUR name) []:www.example.comEmail Address []:webmaster@example.comPlease enter the following 'extra' attributesto be sent with your certificate requestA challenge password []:An optional company name []:To ensure the validity of the CSR, run this command:
openssl req -text -in www.example.com.csr -nooutThe response should look like this:
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/emailAddress=webmaster@example.com 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: ...Submit your CSR to a certificate authority
Different certificate authorities (CAs) require you to submit your CSRs to themin different ways. These can include using a form on their website or sendingthe CSR by email. Some CAs, or their resellers, might even automate some or allof the process, including, in some cases, key pair and CSR generation.
Send the CSR to your CA and follow their instructions to receive your finalcertificate or certificate chain.
Different CAs charge different amounts of money for the service of vouchingfor your public key.
There are also options for mapping your key to more than one DNS name, includingseveral distinct names (e.g. all of example.com, www.example.com, example.net,and www.example.net) or "wildcard" names such as *.example.com.
Copy the certificates to all your front-end servers in a non-web-accessibleplace such as /etc/ssl (Linux and Unix) or wherever IIS (Windows) requiresthem.
Enable HTTPS on your servers
Enabling HTTPS on your servers is a critical step in providing security foryour web pages.
- Use Mozilla's Server Configuration tool to set up your server for HTTPSsupport.
- Regularly test your site with the Qualys' SSL Server Test and ensureyou get at least an A or A+.
At this point, you must make a crucial operations decision. Choose one of thefollowing:
- Dedicate a distinct IP address to each hostname your web server serves contentfrom.
- Use name-based virtual hosting.
If you've been using distinct IP addresses for each hostname, you can supportboth HTTP and HTTPS for all clients. However, most site operators use name-basedvirtual hosting to conserve IP addresses and because it's more convenient ingeneral.
If you don't already have HTTPS service available on your servers, enable it now(without redirecting HTTP to HTTPS. See Redirect HTTP to HTTPSfor more information). Configure your web server to use the certificates youbought and installed. You might find Mozilla's configurationgeneratoruseful.
If you have many hostnames or subdomains, they each need to use the rightcertificate.
Now, and regularly throughout your site's lifetime, check your HTTPSconfiguration with Qualys' SSL Server Test.Your site should score an A or A+. Treat anything that causes a lower grade asa bug, and stay diligent, because new attacks against algorithms and protocolsare always being developed.
Make intrasite URLs relative
Now that you're serving your site on both HTTP and HTTPS, things need to work assmoothly as possible regardless of protocol. An important factor is usingrelative URLs for intrasite links.
Make sure intrasite URLs and external URLs don't depend on a specific protocol.Use relative paths or leave out the protocol as in //example.com/something.js.
Serving a page that contains HTTP resources using HTTPScan cause issues. When a browser encountersan otherwise secure page using insecure resources, it warns users that the pageisn't completely secure, and some browsers refuse to load or execute the HTTPresources, which breaks the page. However, you can safely include HTTPSresources in an HTTP page. For more guidance on fixing these issues, seeFixing Mixed Content.
Following HTTP-based links to other pages on your site can also downgrade theuser experience from HTTPS to HTTP. To fix this, make your intrasite URLs asrelative as possible, by making them either protocol-relative (lacking aprotocol, starting with //example.com) or host-relative (starting with justthe path, like /jquery.js).
Do
<h1>Welcome To Example.com</h1><script src="/jquery.js"></script><link rel="stylesheet" href="/assets/style.css"/><img src="/images/logo.png"/>;<p>A <a href="/2014/12/24">new post on cats!</a></p>
Use relative intrasite URLs.
Do
<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>
Or, use protocol-relative intrasite URLs.
Do
<h1>Welcome To Example.com</h1><script src="/jquery.js"></script><link rel="stylesheet" href="/assets/style.css"/><img src="/images/logo.png"/>;<p>A <a href="/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>
Use HTTPS URLs for links to other sites where possible.
Update your links with a script, not by hand, to avoid making mistakes. If yoursite's content is in a database, test your script on a development copy of thedatabase. If your site's content consists of only simple files, test your scripton a development copy of the files. Push the changes to production only afterthe changes pass QA, as normal. You can use Bram van Damme's scriptor something similar to detect mixed content in your site.
When linking to other sites (as opposed to including resources from them),don't change the protocol. You don't have control over how those sites operate.
To make migration smoother for large sites, we recommend protocol-relative URLs.If you aren't sure whether you can fully deploy HTTPS yet, forcing your site touse HTTPS for all subresources can backfire. There is likely to be a period oftime in which HTTPS is new and weird for you, and the HTTP site must still workas well as ever. Over time, you'll complete the migration and lock in HTTPS(see the next two sections).
If your site depends on scripts, images, or other resources served from a thirdparty, such as a CDN or jquery.com, you have two options:
- Use protocol-relative URLs for these resources. If the third party doesn'tserve HTTPS, ask them to. Most already do, including jquery.com.
- Serve the resources from a server that you control, which offers both HTTPand HTTPS. This is often a good idea anyway, because then you have bettercontrol over your site's appearance, performance, and security, and don't haveto trust a third party to keep your site secure.
Redirect HTTP to HTTPS
To tell search engines to use HTTPS to access your site, put acanonical link at thehead of each page using <link rel="canonical" href="https://…"/> tags.
Turn on Strict Transport Security and secure cookies
At this point, you're ready to "lock in" the use of HTTPS:
- Use HTTP Strict Transport Security (HSTS) to avoid the cost of the 301redirect.
- Always set the Secure flag on cookies.
First, use Strict Transport Securityto tell clients they should always connect to your server using HTTPS, evenwhen following an http:// reference. This defeats attacks likeSSL Stripping,and avoids the round-trip cost of the 301 redirect that we enabled inRedirect HTTP to HTTPS.
To turn on HSTS, set the Strict-Transport-Security header. OWASP's HSTS pagehas links to instructionsfor various kinds of server software.
Most web servers offer a similar ability to add custom headers.
It's also important to make sure clients never send cookies (such as forauthentication or site preferences) over HTTP. For example, if a user'sauthentication cookie were to be exposed in plain text, your security guaranteefor their entire session is destroyed, even if you've done everything elseright!
To avoid this, change your web app to always set the Secure flag on cookies itsets. This OWASP page explains how to set the Secure flagin several app frameworks. Every appl framework has a way to set the flag.
Most web servers offer a simple redirect feature. Use 301 (Moved Permanently)to indicate to search engines and browsers that the HTTPS version is canonical,and redirect your users to the HTTPS version of your site from HTTP.
Search ranking
Google uses HTTPS as a positive search qualityindicator.Google also publishes a guide to how to transferring, moving, or migrating yoursite while maintainingits search rank. Bing also publishes guidelines forwebmasters.
Performance
When the content and application layers are well-tuned (refer toSteve Souders' books for advice), the remaining TLSperformance concerns are generally small relative to the overall cost of theapplication. You can also reduce and amortize those costs. For advice on TLSoptimization, see High Performance Browser Networking byIlya Grigorik, as well as Ivan Ristic'sOpenSSL Cookbook andBulletproof SSL And TLS.
In some cases, TLS can improve performance, mostly as a result of makingHTTP/2 possible. For more information, refer to Chris Palmer's' talk on HTTPS and HTTP/2 performance atChrome Dev Summit 2014.
Referer headers
When users follow links from your HTTPS site to other HTTP sites, user agentsdon't send the Referer header. If this is a problem, there are several ways tosolve it:
- The other sites should migrate to HTTPS. If referee sites complete theEnable HTTPS on your servers section ofthis guide, you can change links in your site to theirs from
http://tohttps://or use protocol-relative links. - To work around a variety of problems with Referer headers, use the newReferrer Policy standard.
Ad revenue
Site operators that monetize their site by showing ads want to make suremigrating to HTTPS doesn't reduce ad impressions. However, because of mixedcontent security concerns, an HTTP <iframe> doesn't work on an HTTPS page.Until advertisers publish over HTTPS, site operators can't migrate to HTTPSwithout losing ad revenue; but until site operators migrate to HTTPS,advertisers have little motivation to publish HTTPS.
You can start the process of breaking this stalemate by using advertisers thatoffer ad services over HTTPS, and asking advertisers that don't serve HTTPS atall to at least make it an option. You might need to defer completingMake IntraSite URLs relative until enough advertisersinteroperate properly.
