This is the most affordable option (anywhere from $20 to $100 per year). Most CAs will only verify the email listed in the whois registration database (see Chapter 2) via a confirmation link. As a consequence, the process of obtaining the certificate is very fast.

It should also be mentioned that a certificate is for a single domain, e.g., for www.funwebdev.com but not api.funwebdev.com. Many CAs also offer more expensive wildcard certificates or even multi-domain certificates (e.g., funwebdev.com and funwebdev.ca) that allow an organization to secure a wider range of domains they own.

With these certificates, the CA takes additional steps to verify the identity of the organization seeking the certificate. While it will perform the same domain verification as with domain-validated certificates, it also typically requests a variety of business documents, such as a government license, bank statement, or legal incorporation records. As a consequence, this type of certificate typically takes several days and is more expensive (sometimes several hundreds of dollars a year).

Why would one choose this type of certificate? It typically provides a much higher warranty amount, which is insurance for the end user against loss of money on a SSL-secured transaction. A more important reason for choosing this type of certificate is that they potentially enhance the user’s trust in the site. How? Some browsers display additional information about OV certificates, as shown in Figure 16.20 (though, based on this author’s student responses to this knowledge, many users seem to be unaware of this feature).

Figure 16.20 Certificates in the browser

These are similar to the organization-validated certificatess, but have even stricter requirements around the documentation that needs to be provided by the purchaser. As well, the purchaser needs to prove their ownership of the domain, which often requires the intervention of a lawyer. The rationale for choosing this option is similar to that of the OV: it’s to improve the trust of the end user.

One of the biggest headaches for web developers working on secure sites is the principle that a secure page requires all assets to be transmitted over HTTPS. Since many domains have secure and insecure areas, it’s not uncommon that assets such as images might be identical for HTTP and HTTPS versions of the site. When a page requested over HTTPS references an asset over HTTP, the browser sees that mixed content is being requested, triggering a range of warning messages.

Once a web developer configures the server to handle HTTPS and the site is running on that server, the site will be deemed secure, since all assets are retrieved using HTTPS. However, in order to fully address a transition from HTTP to HTTPS, developers have to consider every place a HTTP reference exists in their code. Hardcoded links (which are bad style—and now we see why) should be replaced with relative links that easily transform according to the protocol being used. These links might include the following:

• Internal links within the site.

• External links to frameworks delivered through a CDN.

• Any links or references generated by server code that might include a hardcoded http.

Once you move your site over to HTTPS, there likely be links remaining from third-party sites to your former HTTP URLs and it’s important that that such links still work. A permanent redirection (301 code) header in HTTP tells the browser that the link has permanently moved and can be used to tell users and search engines that your site has migrated to HTTPS.

To enable such behavior for every possible resource, both Apache (via a .htaccess file) and Nginx server (via a redirects.conf file) provide mechanisms for redirecting HTTP requests for a resource to HTTPS requests. For instance, in Apache, the following two lines will send a 301 code and the new link location on https.

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Once your site has added HTTPS capabilities, it often makes sense to prevent users from accessing your site resources using HTTP. The rationale for this is to protect users from man-in-the-middle hijacks. Imagine a user accessing your site in a public setting through WiFi. The user’s laptop “remembers” all WiFi names with which it has connected. Perhaps the user frequently uses the WiFi at a popular coffee shop chain or just once has connected to FreeAirportWifi somewhere. The user could be in some other public locale using WiFi (not a coffee shop or airport), and that WiFi name could be provided by a hacker’s laptop in the vicinity that has created a WiFi point using the same name as the coffee chain or airport . The user’s laptop will likely automatically connect to the hacker’s WiFi because its name matches one the user has connected to in the past (for instance FreeAirportWifi). The hacker will then be able to redirect the user from HTTPS to HTTP , thereby having unencrypted access to the user’s experience. The user might perceive the change from HTTPS to HTTP, but he or she might not. As can be seen in Figure 16.22, this attack is a sophisticated varient of the man-in-the-middle attack, and is commonly referred to as a HTTPS downgrade attack.

Figure 16.22 HTTPS downgrade attack.

To protect users against such a scenario, site’s using HTTPS can add the Strict-Transport-Security HTTP header. This header instructs the browser to only accept HTTPS requests for the site. The first time your site is accessed using HTTPS and it returns the Strict-Transport-Security header, the browser will record this fact, so that any future attempts to load the site using HTTP will automatically use HTTPS instead.