The complete guide to moving from HTTP to HTTPS

Nowadays, HTTPS is required for each website : users search for a lock in the address bar when they send personal data; Chrome and Firefox clearly mark insecure websites with forms on non-HTTPS pages; This affects the position in search results and has a serious impact on privacy in general. In addition, there are now several options for getting a free certificate, so switching to HTTPS is just a matter of desire.

Installing HTTPS can be a bit intimidating for an unprepared user - it requires many steps involving various parties, as well as specific knowledge of cryptography and server configurations, and indeed it seems to be generally difficult.

In this guide, I will explain the individual components and steps and outline each installation step clearly. Everything should go smoothly for you, especially if your hoster provides HTTPS certificates itself - then there is a high probability that you will quickly and simply do everything without leaving the control panel.

This includes detailed instructions for virtual hosting owners on cPanel, Apache HTTP and nginx server administrators for Linux and Unix, and Internet Information Server for Windows.

Let's start with the basics.
')

HTTP, HTTPS, HTTP / 2, SSL, TLS: where what?

Many acronyms are used to describe the communication process between the client and the server. People unfamiliar with the technical essence often confuse them.

Hypertext Transfer Protocol (HTTP) is the primary communication protocol that the client and server must support in order to establish a connection. He describes such concepts as requests and responses, sessions, caching, authentication, and others. Sir Tim Berners-Lee and his team at CERN began working on the protocol and also on the Hypertext Markup Language (HTML) hypertext markup language (HTML) in 1989. The first official version of the protocol (HTTP 1.0) was released in 1996, and soon in 1997, HTTP 1.1 appeared, which is widely used today.

The protocol transmits information between the browser and the server in clear text, allowing you to see this information on the network through which it passes. This is a security problem, so HTTP Secure (HTTPS) was invented, allowing the client and server to establish an encrypted communication channel and then transmit messages in plain text over this channel, effectively protecting them from listening.

The terms SSL and TLS are often used interchangeably, since TLS 1.0 comes in place of SSL 3.0. SSL itself was developed by Netscape, and TLS is the IETF standard. At the time of this writing, all versions of SSL (1.0, 2.0, 3.0) are not recommended for use due to various security issues, and modern browsers display warnings about this. TLS uses versions 1.0, 1.1, and 1.2, and version 1.3 is now at the draft stage.

So somewhere between 1996 and 1997 we got the current stable version of the Internet (HTTP 1.1 with or without SSL and TLS), which is still supported on most modern websites. Previously, HTTP was used for irrelevant traffic (for example, reading news), and HTTPS was used for important traffic (for example, authentication and e-commerce): however, increasing privacy means that browsers like Google Chrome now mark HTTP websites as "not confidential ”and in the future will display new warnings for them.

In the next update of the HTTP protocol - HTTP / 2 - which is supported by an increasing number of sites, new functions (compression, multiplexing, priority of different traffic) are implemented in order to reduce delays and increase productivity and security.

In HTTP version 1.1, a secure connection is optional (you can have HTTP and / or HTTPS independently of each other), while in HTTP / 2 it is mandatory in practice - even though the standard allows HTTP / 2 without TLS, but most developers browsers have stated that they implement HTTP / 2 support only via TLS .

What does HTTPS do?

Why you should think about HTTPS first? It is introduced for three main reasons:

Confidentiality
In an open environment such as the Internet, it protects communication between the two parties. For example, in the absence of HTTPS, the owner of the WiFi access point may see private data, such as credit cards, if the user of this access point makes purchases online.
Integrity
He guarantees that the information will reach the addressee in full and intact. For example, our friend with a WiFi access point may add additional advertising to our site, reduce image quality to save traffic, or change the content of articles we read. HTTPS ensures that the website cannot be changed.
Authenticity
He guarantees that the website is in reality the one for whom it claims to be. For example, the same owner of a WiFi access point could send browsers to a fake website. HTTPS ensures that the website, which appears as example.com , is indeed example.com . Some certificates even verify the legal identity of the website owner, so you know that yourbank.com owned by YourBank, Inc.

Cryptography based

Confidentiality, integrity and authentication are not unique features of HTTPS: they are key cryptographic concepts. Let's look at them more closely.

Confidentiality

Confidentiality is privacy - it is, it protects information from being read by unauthorized persons. Typically, this process involves translating information from a readable form (including audio and video), which is called plaintext , into an encrypted, unreadable form, called ciphertext . This process is called encryption . The reverse process — turning an unreadable ciphertext back into readable plaintext — is called decryption . There are many methods for encrypting and decrypting information - encryption functions (or algorithms ).

For the two parties to communicate, they must agree on two issues:

Which algorithm (cryptographic function) to use in communication.
What parameters, passwords or rules (i.e. secret ) will be used with the selected method.

There are two basic encryption methods:

symmetrical
Both parties own a shared secret key .
asymmetrical
One of the parties owns a pair of public and private keys , representing the basis of the public key infrastructure (public key infrastructure, PKI).

Symmetric encryption methods rely on the fact that both parties possess the same secret that the sender uses for encryption, and the recipient for decryption using the same method and the same key (see the illustration below). The problem with these methods is how the parties agree (that is, exchange) about the secret key, without physically meeting each other — they need to establish some kind of secure communication channel.

Symmetric encryption ( see large version )

Asymmetric methods solve problems of this kind - they are based on the concept of public and secret keys. The plaintext is encrypted with one key and can be decrypted using the key pair.

So how does it work? Suppose that we have two parties that want to communicate safely with each other - Alice and Bob (in each textbook such names of fictional characters are always used, in security guides and others, we respect this tradition). Each of them has its own pair of keys: one secret and one public. Secret keys are known only to their respective owners; public keys are open to all.

If Alice wants to send a message to Bob, she must obtain his public key, encrypt the plaintext, and send him a ciphertext. He then uses his secret key to decrypt it.

If Bob wants to send a message to Alice, he must get her public key, encrypt the plaintext and send her a ciphertext. She then uses her secret key to decrypt.

Asymmetric encryption ( see large version )

When we use symmetric, and when asymmetric encryption?

Asymmetric encryption is used to share the secret between the client and the server. In real life, we usually do not need two-way asymmetric communication — it’s enough if one of the parties (let's call its server for simplicity) owns a set of keys so that it can receive encrypted messages. In reality, this only protects information in one direction - from the client to the server, because information encrypted with a public key can only be decrypted using a private secret key: it means that only the server can decrypt it. Another direction is not secure - information encrypted with the server's secret key can be decrypted with its public key, which is open to all. The other party (also, for simplicity, we will call its client ) starts the communication with encrypting a randomly generated session secret with the server's public key, then sends the ciphertext back to the server, which in turn decrypts it with its secret key and now owns the secret.

Then, to protect the real data during transmission, symmetric encryption is used, since it is much faster than asymmetric . Having exchanged a secret, only two parties (client and server) can encrypt and decrypt information.

That is why the first asymmetric part of the handshake is also known as key exchange and that is why encrypted communications use algorithms known as encryption methods .

Integrity

Another problem HTTPS solves is data integrity : 1) a guarantee that all information is delivered in its entirety; 2) a guarantee that no one changes the information during its transmission. To ensure the integrity of information transfer, message digest algorithms are used. The computation of message authentication codes (MAC) for each message in an exchange is a cryptographic hashing process. For example, to obtain a MAC (sometimes called a tag ), a method is used that guarantees the practical impossibility (sometimes the term impracticability is used) to do the following:

change the message without touching the tag,
generate the same tag for two different messages,
reverse the process and get the original message from the tag.

Authentication

What about authenticity ? The problem with real applications of the public key infrastructure is that neither side has a way to know who the other side really is - they are physically separated from each other. To prove its authenticity to the second party, a third party is involved , having mutual trust - a certificate authority (CA) . This CA issues a certificate confirming that the domain name example.com (unique identifier ) is associated with the public key XXX . In some cases (with EV and OV certificates - see below), CA also verifies that a particular company controls this domain. This information is guaranteed (that is, certified) by the certification authority X, and this warranty is valid not earlier than the date Y (that is, the certificate becomes valid from this date), and no later than the date Z (that is, the certificate ends on this date) . All this information is included in a single document called an HTTPS certificate . To give an easily understood analogy - it’s like an ID or a passport issued by the government of the country (that is, a third party that everyone trusts) - and everyone who trusts the government will also trust the certificate (passport) of its owner and the owner himself. It is assumed, of course, that the passport is not a fake, but forging certificates is beyond the scope of this article.

Certificate Authorities are organizations that trust certificate signing. On operating systems such as Windows, macOS, iOS, and Android, as well as in the Firefox browser, there is a list of trusted certificates.

You can check which certification centers your browser trusts:

Firefox
“Options” → “Advanced” → “Certificates” → “View Certificates” → “Authorities”
Windows
“Control Panel” → “Internet Options” → “Content” - “Certificates” → “Trusted Root Certification Authorities / Intermediate Certification Authorities”
Mac
“Applications” → “Utilities” → “Keychain Access.” In the “Category” select “Certificates”

All certificates are then checked and become trusted. The verification is carried out either by the operating system or by the browser - trust is established directly or through a verified trusted party. The trust transfer mechanism is known as a chain of trust :

Chain of trust ( see the larger version )

You can add additional certificate authorities, which is useful when working with self-signed certificates (which we will discuss later).

In most typical situations, the client needs to confirm the identity of the server — for example, an e-commerce site for buyers — so only this website needs a certificate. In other situations, such as e-government systems, both the client and the server must prove their identity. This means that both parties need to present certificates for authentication. Such a system is also beyond the scope of this article.

HTTPS certificate types

There are several types of HTTPS certificates. They can be classified according to the following criteria.

1. Authentication

Verified Domain (DV)
The most common type of DV certificate confirms that a domain corresponds to a specific public key. The browser establishes a secure connection to the server and shows the closed lock icon. Clicking on the icon displays the message "This website has not provided information about the owner." There are no additional requirements for obtaining this certificate, except for domain ownership - the DV certificate simply guarantees that the correct public key is presented for this domain. The browser does not show the name of the legal entity. DV certificates are often cheap ($ 10 per year) or free - see the sections on Let's Encrypt and Cloudflare below.
Extended Confirmation (EV)
EV certificates confirm the legal entity that owns the website. This is the most trustworthy type of certificate. It is issued after the certificate authority checks the legal entity that controls the domain. A legal entity is checked for several conditions:
- domain management (DV certificate availability);
- the state register to verify that the company is registered and valid;
- independent business directories such as Dunn and Bradstreet, connect.data.com from Salesforce, Yellow Pages, etc .;
- verification phone call;
- verification of all domain names in the certificate (wildcard characters are explicitly prohibited in EV certificates).
Like the locked lock icon, EV HTTPS certificates show in front of the URL the name of a verified legal entity - usually a registered company. Some devices, such as iOS Safari, show only a confirmed legal entity, completely ignoring the URL. Clicking on the icon will show details about the organization, such as the full name and legal address. The cost of these certificates ranges from $ 150 to $ 300 per year.
Approved Organization (OV)
Like EV, OV certificates confirm the legal entity that owns the website. But unlike EV, OV HTTPS certificates do not display the name of a verified legal entity in the user interface. As a result, OV certificates are not as popular as they have high requirements for verification, but they do not provide the benefits visible to the user. The cost ranges from $ 40 to $ 100 per year.

2. Number of Covered Domains

In the old days, HTTPS certificates usually contained a single domain in the CN field. A "Subject Alternative Name" (SAN) was added later, so that one certificate covered additional domains. Nowadays, all HTTPS certificates are created in the same way: even in a certificate for a single domain there will be a SAN field for this single domain (and the second SAN field for the www version of this domain). However, many vendors for historical reasons still sell HTTPS certificates for one or more domains.

One domain
This is the most common type of certificate, valid for domain names example.com and www.example.com .
Multiple Domains (UCC / SAN)
This type of certificate, also known as a Unified Communications Certificate (UCC) or Subject Alternative Names (SAN) certificate, can cover a list of domains (up to a certain limit). It is not limited to a single domain - you can specify different domains and subdomains. The cost usually includes a certain number of domains (from three to five) with the ability to add more (up to a certain limit) for an additional fee. It is recommended to use it only with related sites, because the client will see the main domain, as well as all additional, when checking the certificate on any website.
Subdomains (wildcard)
This type of certificate covers the main domain as well as an unlimited number of subdomains ( *.example.com ) - for example, example.com , www.example.com , mail.example.com , ftp.example.com , etc. Restriction in that it covers only the subdomains of the main domain.

A variety of different certificates are shown in the table:

Certificate type	Verified Domain (DV)	Approved Organization (OV)	Extended Confirmation (EV)
	Https	Https Verified holder	Https Verified holder Information about the owner is displayed in the browser.
One domain	`example.com, www.example.com`
Multiple domains	`example.com` , `www.example.com` , `mail.example.com` , `example.net` , `example.org` , etc. A predefined list, up to a certain limit (usually 100)
Subdomains	`*.example.com` Suitable for any subdomain	Not available - all names must be explicitly included in the certificate and verified by a certification authority.

Configuration

To summarize, the four HTTPS components require encryption:

Initial key exchange
Asymmetric algorithms are used (secret and public keys).
Identity certification (HTTPS certificate issued by a certification authority)
Asymmetric algorithms are used (secret and public keys).
Real Message Encryption
Symmetric algorithms are used (previously shared secret shared).
Message digest
Cryptographic hashing algorithms are used.

Each of these components uses a set of algorithms (some of them are no longer recommended for use) with different key sizes. During the handshake, the client and server agree on which combination of methods they will use — choose one of about a dozen different public key algorithms (key exchange), one of about a dozen symmetric key algorithms (cipher) and one of three (two are not recommended for use) algorithms for digest messages, which gives us hundreds of combinations.

For example, selecting ECDHE-RSA-AES256-GCM-SHA384 means that the key exchange will be performed using the Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) algorithm ; The certificate authority signed the certificate using the Rivest-Shamir-Adleman (RSA) algorithm ; symmetric message encryption will use the Advanced Encryption Standard (AES) cipher with a 256-bit key and will work in GCM mode; message integrity will provide a secure SHA hashing algorithm using 384-bit digests. (A full list of combinations of algorithms is available ).

So, you need to make a choice of some configurations.

Cipher Sets

Choosing a cipher suite to use is a trade-off between compatibility and security:

For compatibility with older browsers, you need the server to support old cipher suites.
However, many old cipher suites are no longer considered secure.

OpenSSL lists the supported combinations (see above) in descending order of their cryptographic strength. This is done so that during the initial handshake between the client and the server, they go through the combinations starting from the strongest until they find a combination that is supported by both parties. It makes sense to try the safest combination first and then gradually weaken security if there are no other options.

Wikipedia contains a comprehensive list of algorithms for all TLS components and indicates their support in different versions of SSL and TLS.

Mozilla SSL Configuration Generator is a very useful and highly recommended reference book on which cryptographic methods to use on the server. We will use it later in real server configurations.

Key Types

Elliptic Curve Cryptography ( ECC ) certificates are faster processed and use less CPU than RSA certificates, which is especially important for mobile clients. However, some services, such as Amazon, CloudFront, and Heroku, at the time of this writing, do not yet support ECC certificates.

A 256-bit key length for ECC is considered sufficient.

Rivest Shamir Adleman ( RSA ) certificates are slower, but compatible with a wide variety of older servers. The RSA keys are larger in size, so the 2048-bit RSA key is considered the minimum allowed. RSA certificates with keys of 4096 bits and more can degrade performance - besides, most likely, they are signed with a 2048-bit intermediary key, which for the most part undermines additional protection!

You may have noticed the vagueness of the statements made above and the absence of any numbers. What one server can load will not load another server. The best way to determine the impact on performance is to check the download on your own server, with a real website and real visitors. And even that will change with time.

Procedures

To obtain HTTPS certificates, complete the following steps:

Create a pair of private and public keys and prepare a certificate signing request (CSR), including information on the organization and the public key.
Contact a certificate authority and request an HTTPS certificate based on CSR.
Get a signed HTTPS certificate and install it on your server.

There is a set of files containing various components of a public key infrastructure (PKI): a private key and a private key, a CSR, and a signed HTTPS certificate.To make things even more complicated, different parties use different names (and extensions) to name the same thing.

To begin with, there are two popular storage formats for information - DER and PEM. The first one (DER) is binary, and the second (PEM) is the base64 encoded DER file (text). By default, Windows directly uses the DER format, and the world of free systems (Linux and UNIX) uses the PEM format. There are tools (OpenSSL) for converting files from one format to another.

We will use the following files as examples:

example.com.key
PEM file with secret key. Expansion is .keynot a standard, so someone can use it, and someone not. The file must be protected and accessible only to the superuser.
example.com.pub
PEM . ( ), . .
example.com.csr
. PEM , . , HTTPS.
example.com.crt
HTTPS, . PEM, , , , . .crt ; , .cert .cer .

( ) ; . , , . , , — .

— ( 2048 ), :

! , (600) .

— — :

CSR ACME Inc., , , example.com .

, HTTPS :

. — , .

, cPanel, Linux, FreeBSD Windows. , . DV, , Let's Encrypt Cloudflare .

1.

2048- RSA, . , , ECC (, Heroku AWS), ECC.

cPanel

cPanel .
“Security” “SSL/TLS”.

“Security” cPanel ( . )
“SSL/TLS Manager”. “Private Keys (KEY)” .

“SSL/TLS Manager” cPanel ( . )
“Generate, Paste or Upload” “Private
Key”. 2048 “Generate”.

(“Private Key”) cPanel ( . )
, :

cPanel ( . )
“Private Keys”, :

“Private Keys” cPanel ( . )
“SSL/TLS Manager”. “Certificate Signing Requests (CSR)” .

“SSL/TLS Manager” cPanel ( . )
“Generate Service Request”. . ( !), “Domains”, , HTTPS. ( example.com ); www ( www.example.com ). “Generate”.

“Create New Certificate Signing Request” cPanel ( . )
CSR, :

CSR cPanel ( . )
“Certificate Signing Request”, CSR:

“Certificate Signing Request” cPanel CSR ( . )

Linux, FreeBSD

, OpenSSL. :

openssl version

, :

Debian, Ubuntu
sudo apt-get install openssl
Red Hat, CentOS
sudo yum install openssl
FreeBSD
make -C /usr/ports/security/openssl install clean

CSR :

openssl req -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr

, CSR:

Generating a 2048 bit RSA private key
........................+++
................................................................+++
writing new private key to 'example.com.key'
-----
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.

( !), “Common Name” (, FQDN ) , , HTTPS. ( example.com ); www ( www.example.com ):

Country Name (2 letter code) [AU]:GB
State or Province Name (full name) [Some-State]:London
Locality Name (eg, city) []:London
Organization Name (eg, company) [Internet Widgits Pty Ltd]:ACME Inc.
Organizational Unit Name (eg, section) []:IT
Common Name (eg server FQDN or YOUR name) []:example.com
Email Address []:admin@example.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Internet Information Server Windows

“Start” → “Administrative Tools” → “Internet Information Services (IIS) Manager”. . “Server Certificates” :

“Internet Information Services (IIS) Manager”. “Server Certificates”. ( . )
“Create Certificate Request” .

“Create Certificate Request” . ( . )
, “Common Name”, . “Next”.

. ( . )
“Cryptographic Service Provider.” “Bit length” 2048 . “Next”.

“Bit length” 2048 . ( . )
CSR “Finish”.

CSR “Finish”. ( . )

2. HTTPS

To obtain a certificate for your web site, first purchase a credit for an HTTPS certificate of the chosen type (DV, OV, EV, one site, several sites, subdomains - see above) from the seller of certificates. At the end of the process, you will need to send a request for a certificate that will spend the purchased credit for the selected domain. You will be asked to provide (that is, insert in the download field) all the CSR text, including the lines -----BEGIN CERTIFICATE REQUEST-----and -----END CERTIFICATE REQUEST-----. If you need an EV or OV certificate, you will need to specify the legal entity for which you are requesting a certificate. You may also be asked for additional documents confirming the fact that you represent this company. The certificate registrar will then verify your request (and all related documents) and issue a signed HTTPS certificate.

Getting HTTPS certificate

Your hosting provider or HTTPS registrar may have a different registration procedure, but the general logic is the same.

Find a vendor of HTTPS certificates.
Choose a certificate type (DV, OV, EV, one site, several sites, subdomains) and add it to the cart. Choose your preferred payment method and make a payment.
Activate a new HTTPS certificate for your domain. You can either insert into the form, or upload a file with a certificate signing request. The system will extract the certificate information from the CSR.
« » (“Domain Control Validation”, DCV) — , HTML ( HTML ), TXT ( DNS ). DCV .
, HTTPS. .

, . , , , — , . -, , .

, — example.com , .

, OpenSSL.

openssl x509 -signkey example.com.key -in example.com.csr -req -days 365 -out example.com.crt

Once the certificate is generated, you need to install it on your server. If you have a hosting and HTTPS registration service from a single provider (many hosting providers also sell HTTPS certificates), then the automatic procedure for installing and activating your new HTTPS certificate for the website may be applied. If you are hosted somewhere else, then you need to download a certificate and configure the server to use it.

Step 3. Install the HTTPS certificate for your website

cPanel

Return to the “SSL / TLS Manager”. Click “Certificates (CRT)” to import the new certificate.

Section “SSL / TLS Manager” in cPanel ( see large version )
“Paste, Upload or Generate” “Certificate”. , HTTPS, “Browse”.

HTTPS cPanel ( . )
HTTPS, , . “Save Certificate”.

HTTPS cPanel ( . )
, .

HTTPS cPanel ( . )
“Certificates (CRT)”, HTTPS.

“Certificates” cPanel HTTPS. ( . )
“SSL/TLS Manager”. “Install and Manage SSL for your website (HTTPS)”, - .

“SSL/TLS Manager” cPanel. ( . )
“Install an SSL Website”. “Browse Certificates” HTTPS. - ( ) “Certificate” “Private Key”.

“Install an SSL Website” cPanel. ( . )

, - https://www.example.com . , , , HTTP- HTTPS. .htaccess ( - Apache) .

RewriteEngine On

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

.htaccess , RewriteCond RewriteRule RewriteEngine On .

Linux, FreeBSD

( example.com.key ), ( example.com.csr ) HTTPS ( example.com.crt ):

Debian, Ubuntu , FreeBSD
cp example.com.crt /etc/ssl/certs/ cp example.com.key /etc/ssl/private/ cp example.com.csr /etc/ssl/private/
Red Hat, CentOS
cp example.com.crt /etc/pki/tls/certs/ cp example.com.key /etc/pki/tls/private/ cp example.com.csr /etc/pki/tls/private/ restorecon -RvF /etc/pki

600 .

Debian, Ubuntu
chown -R root. /etc/ssl/certs /etc/ssl/private chmod -R 0600 /etc/ssl/certs /etc/ssl/private
Red Hat, CentOS
chown -R root. /etc/pki/tls/certs /etc/pki/tls/private chmod -R 0600 /etc/pki/tls/certs /etc/pki/tls/private
FreeBSD
chown -R root:wheel /etc/ssl/certs /etc/ssl/private chmod -R 0600 /etc/ssl/certs /etc/ssl/private

Apache

HTTPS , :

, mod_ssl ,
HTTPS ( .crt ),
Apache.

mod_ssl . , :

apache2 -M | grep ssl
or
httpd -M | grep ssl

mod_ssl , …

ssl_module (shared)
Syntax OK

… .

, :

Debian, Ubuntu
sudo a2enmod ssl sudo service apache2 restart
Red Hat, CentOS
sudo yum install mod_ssl sudo service httpd restart
FreeBSD
make -C /usr/ports/www/apache24 config install clean apachectl restart

Apache (httpd.conf):

Debian, Ubuntu
/etc/apache2/apache2.conf
Red Hat, CentOS
/etc/httpd/conf/httpd.conf
FreeBSD
/usr/local/etc/apache2x/httpd.conf

 Listen 80 Listen 443 <VirtualHost *:80> ServerName example.com ServerAlias www.example.com Redirect 301 / https://www.example.com/ </VirtualHost> <VirtualHost *:443> ServerName example.com Redirect 301 / https://www.example.com/ </VirtualHost> <VirtualHost *:443> ServerName www.example.com ... SSLEngine on SSLCertificateFile/path/to/signed_certificate_followed_by_intermediate_certs SSLCertificateKeyFile /path/to/private/key # Uncomment the following directive when using client certificate authentication #SSLCACertificateFile /path/to/ca_certs_for_client_authentication # HSTS (mod_headers is required) (15768000 seconds = 6 months) Header always set Strict-Transport-Security "max-age=15768000" ... </VirtualHost> # intermediate configuration, tweak to your needs SSLProtocol all -SSLv3 SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS SSLHonorCipherOrder on SSLCompression off SSLSessionTickets off # OCSP Stapling, only in httpd 2.3.3 and later SSLUseStapling on SSLStaplingResponderTimeout 5 SSLStaplingReturnResponderErrors off SSLStaplingCache shmcb:/var/run/ocsp(128000)

Mozilla SSL Configuration Generator . . . — , .

, HTTP HTTPS, - www www ( SEO).

Nginx

nginx ( nginx.conf ):

Debian, Ubuntu, Red Hat, CentOS
/etc/nginx/nginx.conf

FreeBSD
/usr/local/etc/nginx/nginx.conf

 server { listen 80 default_server; listen [::]:80 default_server; # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response. return 301 https://$host$request_uri; } server { listen 443 ssl http2; listen [::]:443 ssl http2; # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate ssl_certificate /path/to/signed_cert_plus_intermediates; ssl_certificate_key /path/to/private_key; ssl_session_timeout 1d; ssl_session_cache shared:SSL:50m; ssl_session_tickets off; # Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits ssl_dhparam /path/to/dhparam.pem; # intermediate configuration. tweak to your needs. ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS'; ssl_prefer_server_ciphers on; # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months) add_header Strict-Transport-Security max-age=15768000; # OCSP Stapling --- # fetch OCSP records from URL in ssl_certificate and cache them ssl_stapling on; ssl_stapling_verify on; ## verify chain of trust of OCSP response using Root CA and Intermediate certs ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates; resolver <IP DNS resolver>; .... }

Mozilla SSL Configuration Generator . . . — , .

HTTP HTTPS HTTP/2!

Internet Information Server Windows

“Start” → “Administrative Tools” → “Internet Information Services (IIS) Manager”. . “Server Certificates” .

“Internet Information Services (IIS) Manager”. “Server Certificates”. ( . )
“Complete Certificate Request” .

“Complete Certificate Request” . ( . )
( example.com.crt ), . - “Friendly name”, . “Personal” (IIS 8+). “OK”.

. ( . )
, “Server Certificates”.

“Server Certificates”. ( . )
. “Sites” -, HTTPS. “Bindings” .

- “Bindings”. ( . )
“Site Bindings” “Add”.

“Add”. ( . )
:
- “Type”: “https”
- “IP address”: “All Unassigned”
- “Port”: “443”
“SSL Certificate” HTTPS . “OK”.

“HTTPS” HTTPS. ( . )
- HTTP HTTPS.

- HTTP HTTPS. ( . )

« ! ( )». , : , (, , .), , http:// . ( /images/image.png , /styles/style.css . .) ( ../images/image.png ), URL, https:// , <script src="https://code.jquery.com/jquery-3.1.0.min.js"></script> .

, .

, HTTPS, Qualys SSL Server Test . -, , . .

Extension

— . — , . . : , HTTPS . , . , , . , , , -.

Feedback

, - , HTTPS. , , HTTPS. , , , , . .

Let's Encrypt

Let's Encrypt :

Let's Encrypt — , (CA), . Let's Encrypt Internet Security Research Group (ISRG) .

Let's Encrypt:

Let's Encrypt .
Automation
- Let's Encrypt , .
Security
Let's Encrypt TLS, , - .

.

, .

, , Let's Encrypt — , - .

Let's Encrypt, . Let's Encrypt , , - HTTPS .

How it works

Let's Encrypt . , , :

HTTPS Let's Encrypt .
Automation
HTTPS Let's Encrypt 90 , HTTPS, . ; , ( cron) — « ».
Security
HTTPS Let's Encrypt , . , .

Restrictions

Let's Encrypt only issues DV certificates. OV and EV certificates are not supported, and there are currently no plans to support them. Certificates are issued for one or several domains, but at the moment there are no certificates with subdomains (wildcards). For more information, see the Let's Encrypt FAQ .

The automatic mode of operation Let's Encrypt imposes some restrictions on use to protect the infrastructure from intentional and unintentional abuse. The usage limits are high enough to prevent ordinary users with even hundreds of domains available. But if you manage HTTPS certificates on a very large scale, then you should familiarize yourself with these limits.

( Windows XP SP3) . . .

HTTPS Let's Encrypt

cPanel

cPanel .
“Security” “Let's Encrypt for cPanel”.

“Security” cPanel. ( . )
“Let's Encrypt for cPanel”. ( example.com www.example.com ) “Issue Multiple”.

“Issue Multiple”. ( . )
. ( - www , www , “Subject Alt Name” (SAN) HTTPS. “Issue”. , , — .

“Issue” . ( . )
, . «», .

, . ( . )
You will see your domain in the list “Your domains with Let's Encrypt certificates”. You can check the details of the certificate and make sure that the website opens in a browser with a prefix https://.

Your domains with Let's Encrypt certificates. ( see big version )

Linux, FreeBSD, others

The easiest way to install Let's Encrypt certificate on your server is to use Certbot . Simply enter your website and operating system - and follow the instructions.

Certbot for Let's Encrypt ( see big version )

Internet Information Server for Windows

IIS Windows, .

Windows- Let's Encrypt:

ACMESharp (PowerShell) — Windows-.
letsencrypt-win-simple ( ) .
Certify GUI ACMESharp, -.

Cloudflare

Cloudflare — , (CDN), - DDoS-. HTTPS , — DV Cloudflare Universal SSL. HTTPS, -.

, - “Crypto”.

CertSimple

CertSimple EV. EV HTTPS, Let's Encrypt DV HTTPS, , . Here are its benefits:

. , .
, , 7-10 .
.

- HTTPS IP-

- IP- TLS. , HTTP, HTTPS TLS , HTTP — , - HTTP, . , , . , TLS .

: IP- TLS, . — IPv4 , HTTPS , .

TLS Server Name Indication (SNI) . , . SNI , - 100%, .

SNI Apache , nginx IIS (8+) . .

Useful resources

Mozilla SSL Configuration Generator
SSL , Qualys
TLS , Mozilla
SSL TLS , SSL Labs
, Qualys SSL Labs
PHP , Interconnect IT. HTTP HTTPS (, .) WordPress.

Source: https://habr.com/ru/post/332294/

All Articles

The complete guide to moving from HTTP to HTTPS

HTTP, HTTPS, HTTP / 2, SSL, TLS: where what?

What does HTTPS do?

Cryptography based

Confidentiality

Integrity

Authentication

HTTPS certificate types

1. Authentication

2. Number of Covered Domains

Configuration

Cipher Sets

Key Types

Procedures

1.

cPanel

Linux, FreeBSD

Internet Information Server Windows

2. HTTPS

Getting HTTPS certificate

Step 3. Install the HTTPS certificate for your website

cPanel

Linux, FreeBSD

Apache

Nginx

Internet Information Server Windows

Extension

Feedback

Let's Encrypt

How it works

Restrictions

HTTPS Let's Encrypt

cPanel

Linux, FreeBSD, others

Internet Information Server for Windows

Cloudflare

CertSimple

- HTTPS IP-

Useful resources

More articles: