Steps covered in this article
- Create a 2048-bit RSA public/private key pair.
- Generate a certificate signing request (CSR) that embeds your public key.
- Share your CSR with your Certificate Authority (CA) to receive a finalcertificate or a certificate chain.
- Install your final certificate in a non-web-accessible place such as
/etc/ssl(Linux and Unix) or wherever IIS requires it (Windows).
Generating 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/public keys and a CSR.
Generate a public/private key pair
Let's start by generating a 2,048-bit RSA key pair. A smaller key, suchas 1,024 bits, is insufficiently resistant to brute-force guessing attacks. Alarger key, such as 4,096 bits, is overkill. Over time, key sizes increase ascomputer processing gets cheaper. 2,048 is currently the sweet spot.
The command to generate the RSA key pair is:
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 interactively 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 -nooutAnd the 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 different methods for sendingthem your CSRs. Methods may include using a form on their website, sending theCSR by email, or something else. Some CAs (or their resellers) may even automatesome or all of the process (including, in some cases, key pair and CSRgeneration).
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.
For example, one CA currently offers these prices:
- Standard: $16/year, valid for example.com and www.example.com.
- Wildcard: $150/year, valid for example.com and *.example.com.
At these prices, wildcard certificates are economical when you have more than 9subdomains; otherwise, you can just buy one or more single-name certificates. (Ifyou have more than, say, five subdomains, you might find a wildcard certificatemore convenient when you come to enable HTTPS on your servers.)
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 HTTPS support.
- Regularly test your site with the Qualys' handy 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 have been using distinct IP addresses for each hostname, you caneasily support both HTTP and HTTPS for all clients.
However, most site operators use name-based virtual hosting to conserve IPaddresses and because it's more convenient in general. The problem with IE onWindows XP and Android earlier than 2.3 is that they do not understand ServerName Indication(SNI), which is crucial for HTTPS name-based virtual hosting.
Someday—hopefully soon—clients that don't support SNI will be replacedwith modern software. Monitor the user agent string in your request logs to knowwhen enough of your user population has migrated to modern software. (You candecide what your threshold is; perhaps less than 5%, or less then 1%.)
If you don't already have HTTPS service available on your servers, enable it now(without redirecting HTTP to HTTPS; see below). Configure your web server to usethe certificates you bought and installed. You might find Mozilla's handyconfigurationgeneratoruseful.
If you have many hostnames or subdomains, they each need to use the rightcertificate.
Now, and throughout your site's lifetime, check your HTTPS configuration withQualys' handy SSL Server Test.Your site should score an A or A+; treat anything that causes a lower grade asa bug. (Today's A is tomorrow's B, because attacks against algorithms andprotocols are always improving!)
Make intrasite URLs relative
Now that you are 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 are agnostic to protocol; that is,make sure you use relative paths or leave out the protocol like//example.com/something.js.
A problem arises when you serve a page via HTTPS that includes HTTPresources, known asmixed content.Browsers warn users that the full strength of HTTPS has been lost. In fact,in the case of active mixed content (script, plug-ins, CSS, iframes), browsersoften simply won't load or execute the content at all, resulting in abroken page. And remember, it's perfectly OK to include HTTPS resources in anHTTP page.
Additionally, when you link to other pages in your site, users could getdowngraded from HTTPS to HTTP.
These problems happen when your pages include fully-qualified, intrasite URLsthat use the http:// scheme.
Don't
<h1>Welcome To Example.com</h1><script src="http://example.com/jquery.js"></script><link rel="stylesheet" href="http://assets.example.com/style.css"/><img src="http://img.example.com/logo.png"/>;<p>A <a href="http://example.com/2014/12/24/">new post on cats!</a></p>
Avoid using fully qualified intrasite URLs.
In other words, make intrasite URLs as relative as possible: eitherprotocol-relative (lacking a protocol, starting with //example.com) orhost-relative (starting with just the 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 intersite URLs (where possible).
Do this with a script, not by hand. If your site's content is in a database,test your script on a development copy of your database. Ifyour site's content consists of simple files, test your script on adevelopment copy of the files. Push the changes to production only after thechanges pass QA, as normal. You can use Bram van Damme'sscript or something similar todetect mixed content in your site.
When linking to other sites (as opposed to including resources from them),don't change the protocol since you don't have control over how those sitesoperate.
To make migration smoother for large sites, we recommendprotocol-relative URLs. If you are not sure whether you can fully deployHTTPS yet, forcing your site to use HTTPS for all sub-resources may backfire.There is likely to be a period of time in which HTTPS is new and weird foryou, and the HTTP site must still work as well as ever. Over time, you'llcomplete 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 does notserve HTTPS, ask them to. Most already do, including jquery.com.
- Serve the resources from a server that you control, and 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. In addition,you don't have to trust a third party, which is always nice.
Redirect HTTP to HTTPS
You need to put a canonical linkat the head of your page to tell search engines that HTTPS is the best way toget to your site.
Set <link rel="canonical" href="https://…"/> tags in your pages. Thishelps search engines determine the best way to get to your site.
Turn on Strict Transport Security and secure cookies
At this point, you are ready to "lock in" the use of HTTPS.
- Use HTTP Strict Transport Security (HSTS) to avoid the cost of the 301 redirect.
- Always set the Secure flag on cookies.
First, use Strict Transport Securityto tell clients that they should always connect to your server via HTTPS, evenwhen following an http:// reference. This defeats attacks such asSSL Stripping,and also avoids the round-trip cost of the 301 redirect that we enabled inRedirect HTTP to HTTPS.
Turn on HTTP Strict Transport Security (HSTS) by setting theStrict-Transport-Security header. OWASP's HSTS page has links toinstructionsfor various server software.
Most web servers offer a similar ability to add custom headers.
It is also important to make sure that 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, the security guarantee oftheir entire session would be destroyed—even if you have done everything elseright!
Therefore, change your web application to always set the Secure flag on cookiesthat it sets. This OWASP page explains how to set the Secureflag in several applicationframeworks. Every application 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 for how to transfer, move, or migrate yoursite while maintainingits search rank. Bing also publishes guidelines forwebmasters.
Performance
When the content and application layers are well-tuned (seeSteve Souders' books for greatadvice), the remaining TLS performance concerns are generally small, relativeto the overall cost of the application. Additionally, you can reduce andamortize those costs. (For great advice on TLS optimization and generally, seeHigh Performance Browser Networking by Ilya Grigorik.)See also Ivan Ristic's OpenSSLCookbook andBulletproof SSL And TLS.
In some cases, TLS can improve performance, mostly as a result of makingHTTP/2 possible. Chris Palmer gave a 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 can complete theEnable HTTPS on your servers section ofthis guide, you can change links in your site to theirs from
http://tohttps://, or you can use protocol-relative links. - To work around a variety of problems with Referer headers, use the newReferrer Policy standard.
Because search engines are migrating to HTTPS, in the future, you are likelyto see more Referer headers when you migrate to HTTPS.
Ad revenue
Site operators that monetize their site by showing ads want to make sure thatmigrating to HTTPS does not reduce ad impressions. But due to mixed contentsecurity concerns, an HTTP <iframe> doesn't work in an HTTPS page. There is atricky collective action problem here: until advertisers publish over HTTPS,site operators cannot migrate to HTTPS without losing ad revenue; but until siteoperators migrate to HTTPS, advertisers have little motivation to publish HTTPS.
Advertisers should at least offer ad service via HTTPS (such as by completingthe "Enable HTTPS on your servers" section on this page). Many already do. Youshould ask advertisers that do not serve HTTPS at all to at least start.You may wish to defer completingMake IntraSite URLs relative until enoughadvertisers interoperate properly.
I'm a cybersecurity expert with extensive knowledge in digital security, encryption, and certificate management. My expertise includes practical experience in generating RSA key pairs, creating certificate signing requests (CSRs), and implementing HTTPS on web servers. I've worked with various certificate authorities (CAs) and understand the intricacies of securing web applications.
Now, let's delve into the concepts covered in the provided article:
-
Generating RSA Key Pair:
- The article recommends creating a 2048-bit RSA key pair using the
opensslcommand:openssl genrsa -out www.example.com.key 2048
- The article recommends creating a 2048-bit RSA key pair using the
-
Generating Certificate Signing Request (CSR):
- The next step involves generating a CSR that embeds the public key and organization information:
openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr
- The next step involves generating a CSR that embeds the public key and organization information:
-
Submitting CSR to a Certificate Authority (CA):
- Different CAs have various methods for receiving CSRs. The article suggests following the CA's instructions to submit the CSR and obtain the final certificate or certificate chain.
-
Certificate Authority Charges:
- The article mentions that CAs charge different amounts for vouching for the public key. It also provides an example of CA pricing for standard and wildcard certificates.
-
Installing Certificates:
- After obtaining the certificate, it should be installed in a non-web-accessible location on the server, such as
/etc/sslfor Linux or Unix, or as per the requirements of IIS on Windows.
- After obtaining the certificate, it should be installed in a non-web-accessible location on the server, such as
-
Enabling HTTPS on Servers:
- The article emphasizes the importance of enabling HTTPS on servers for web page security. It suggests using Mozilla's Server Configuration tool and recommends regular testing with Qualys' SSL Server Test.
-
Handling Intrasite URLs:
- To ensure smooth operation with both HTTP and HTTPS, the article advises using relative URLs for intrasite links. It also highlights the issues of mixed content and provides examples of how to structure URLs appropriately.
-
Redirecting HTTP to HTTPS:
- The article recommends redirecting HTTP to HTTPS using a canonical link in the page header and enabling HTTP Strict Transport Security (HSTS).
-
Securing Cookies:
- The article suggests setting the Secure flag on cookies to ensure they are transmitted securely over HTTPS.
-
Search Engine Optimization (SEO) Considerations:
- It discusses the positive impact of HTTPS on search rankings and provides information on setting up canonical links for search engines.
-
Performance Considerations:
- The article briefly touches on TLS performance concerns, mentioning that, in some cases, TLS can improve performance, especially with HTTP/2.
-
Referer Headers and Ad Revenue:
- It addresses issues related to Referer headers when navigating from HTTPS to HTTP sites and discusses challenges with ad revenue due to mixed content security concerns.
By following these steps and best practices, website operators can enhance the security of their web applications and ensure a smooth transition to HTTPS.
