Build an HTTPS server with a self-built CA certificate

1. Introduction to theoretical knowledge of HTTPS

HTTPS (full name: Hyper Text Transfer Protocol over secure Socket Layer) is a security-targeted HTTP channel and is simply a secure version of HTTP. That is, the SSL layer is added under HTTP, the security base of HTTPS is SSL, so the detailed content of encryption needs SSL.

The Hypertext Transfer Protocol HTTP protocol is used to pass information between a Web browser and a Web server. The HTTP protocol sends content in plaintext, does not provide data encryption in any way, and if an attacker intercepts a transmission message between a Web browser and a Web server, it can read the information directly, so the HTTP protocol is not suitable for transmitting sensitive information such as credit card numbers, passwords, etc.

To address this flaw in the HTTP protocol, you need to use a different protocol: Secure Sockets Layer Hypertext Transfer Protocol HTTPS. For the security of data transmission, HTTPS joins the SSL protocol on the basis of HTTP, SSL relies on the certificate to verify the identity of the server, and encrypts the communication between the browser and the server.

The main differences between HTTPS and HTTP are the following four points:

• The HTTPS protocol requires a certificate to be applied to the CA, and the general free certificate is very small and requires a fee.
• HTTP is a Hypertext Transfer Protocol, the information is plaintext transmission, HTTPS is a secure SSL encryption transport protocol.
• HTTP and HTTPS use a completely different connection, the same port, the former is 80, the latter is 443.
• The HTTP connection is simple and stateless; The HTTPS protocol is a network protocol built by the SSL+HTTP protocol for encrypted transmission and authentication, which is more secure than the HTTP protocol.

Simply put, HTTPS is based on the HTTP nested SSL protocol, thus to achieve identity authentication, to understand SSL, but also to explain the asymmetric encryption system.

Asymmetric encryption

There is asymmetric encryption, then of course there is symmetric encryption, the following is a brief talk about the difference between the two.

• symmetric encryption : refers to the encryption and decryption using the same key, the sender uses secret key A to encrypt the information, and then transfer ciphertext, the recipient uses key A to decrypt the ciphertext, get information. If you use key B to decrypt the ciphertext at this time, you cannot decrypt it. To ensure the reliability of the encryption, both the sender and the recipient must ensure that key A is not compromised.
• Asymmetric Encryption : Use a pair of keys for encryption and decryption operations, called Public and private keys, respectively, public and private keys are generated in pairs, the public key is often public, anyone can get, the private key is confidential, only a specific talent owned. Asymmetric encryption has two typical usage scenarios, namely encryption and authentication .
  • Encryption : Encryption is meant to transmit information that needs to be kept confidential, so it is necessary to ensure that only certain people can decrypt the information. The sender then uses public key A to encrypt and the recipient uses the private key A to decrypt. Assuming that everyone has public key A, only Zhang San has private key A, then the other person wants to send the message to Zhang San, only to use public key A to encrypt the information, then the ciphertext only has the private key a Zhang San can decrypt.
  • Verify : The verification is to prove to others that "I am Me" problem. Here, the sender uses the private key for a signature, and the recipient uses public key A for authentication. Or assume that everyone has a public key A, only Zhang San has a private key A, now Zhang three to others to prove that they are Zhang San, so Zhang San will "I am Zhang San" This piece of information using private key A to sign, send to other people, others use public key a decryption, get signed "I am Zhang San", So the other person thought the message was sent by Zhang San. One problem here is that anyone can use their private key to sign the "I am Zhang San" to counterfeit the Zhang San, assuming there is a John Doe, he signed "I am Zhang San" with his private key B, which makes other people with public key B think John Doe is Zhang San. The solution to this problem is to ensure that the authentication public key authority, CA is to solve this problem, CA (Certificate authority), also known as e-commerce Certification Center, is responsible for the issuance and management of digital certificates Authority, and as a trusted third party in e-commerce transactions, Assume responsibility for the legality test of public key in public key system. The CA-specific process is again.

HTTPS setup process

First, this diagram shows the process of HTTPS creation.

Here's a brief explanation of the process:

• The CA is established and issued to its own root certificate. That is, the CA uses its own private key to package the CA's authentication information and its own public key into a root certificate.
• The CA has contacted the browser vendor (browser vendor) to tell the browser vendor of its own certificate, and if the browser manufacturer trusts the CA, it will add the CA's certificate to the browser it has developed.
• A web site that wants to get HTTPS service, first to send its own authentication information and its own public key to the CA, and to the CA to request their own certificate, the CA after verifying the legality of the site, the CA's own private key to the website authentication information and public key packaging encryption, form the certificate of this website, This certificate is issued to the website.
• Now the site has its own certificate, so he can build his own HTTPS services.
• Now a client wants to use the site's HTTPS service, and the site sends its own certificate to the client. The client authenticates the Web site certificate with the CA's certificate, verifies the error and establishes a secure connection, the SSL handshake process .
  • Started by the client. The client sends the SSL version, as well as the encryption and compression algorithms to the server. The server checks whether this version of SSL is supported and initiates the encryption and compression algorithms that the client expects.
  • After the base configuration is complete, the server sends its own certificate. The certificate must be trusted by the client, or by a CA that the client trusts.
  • The client verifies the certificate and verifies that the server's identity is correct.
  • After the verification is complete, the encryption is used after negotiation, and the client tells the server that all data swaps are encrypted from now on and sends an encrypted authentication "message" to the server.
  • Server authentication is sent by the client, and "message" can be decrypted. The server sends the decrypted message to the client. After the client verifies, secure the connection. The handshake is over.
• After that, the client and the server can use the HTTPS service for encrypted communication, but then the communication is generally implemented with symmetric encryption, since symmetric encryption has fewer resources than asymmetric encryption.

2. Build HTTPS Service

Native environment: Ubuntu 17.10, Openssl 1.0.2g, FireFox 57.0.1 (64-bit), Apache 2.4.27

First confirm the installation of OpenSSL

To determine the OpenSSL version:

$openssl version

If the version is below 1.0.1f, it is recommended to upgrade because OpenSSL under the 1.0.1f version has a Heartbleed vulnerability.
Installing OpenSSL:

$sudo apt-get install openssl

Self-built CA

Because it takes a fee to request a signature from a CA, we choose to build a CA to complete the process.
First, set up the Myca directory to hold CA-related information

cd && mkdir -p myCA/signedcerts && mkdir myCA/private && cd myCA

MyCA is used to store the CA root certificate, the certificate database, and subsequent server-generated certificates, keys, and requests
Signedcerts: Save copy of the signing certificate
Private: Contains the private key

Then configure the Myca related parameters, in the Myca directory

echo ‘01‘>serial && touh index.txt

Then create the caconfig.cnf file

vim ~/myCA/caconfig.cnf

CACONFIG.CNF file contents are as follows

# My Sample caconfig.cnf file.## Default configuration to use if one is not provided on the command line.#[CA]default_             CA = local_ca### Default location of directories and files needed to generate certificates.#[Local_ca]dir        =/home/<username>/myca # here to replace username with your username certificate = $dir/cacert.pemdatabase       = $dir/index.txtnew_certs_dir = $dir/signedcertsprivate_key = $dir/private/cakey.pemserial = $dir/serial#            # # Default expiration and encryption policies for certificates. #default_crl_days = 365default_days       = 1825DEFAULT_MD = sha256# Policy = Local_ca_policyx509_extensions = local_ca_extensions#  # # Default policy to use when generating server certificates. The following# fields must is defined in the server certificate.#[local_ca_policy]commonname = Suppliedstat    Eorprovincename = Suppliedcountryname = suppliedemailaddress        = Suppliedorganizationname = Suppliedorganizationalunitname = supplied# # # X509 extensions to use WH  En generating Server certificates.#[local_ca_extensions]subjectaltname = dns:localhostbasicconstraints =    Ca:falsenscerttype = server# # # The default root certificate generation policy.#[req]default_bits       = 2048default_keyfile =/home/<username>/myca/private/cakey.pem # here to replace username with your username DEFAULT_MD = sha256# prompt = Nodistinguished_name = Root_ca_distinguished_namex509_extensions = Root_ca_exte  nsions### Root Certificate Authority distinguished name. Change these fields to match# your local environment!#[root_ca_distinguished_name]commonname = Myown root C Ertificate Authority # CA Institution Name stateorprovincename = JS # ca Province countryname = C N # Country of CA (2 characters only) EmailAddress = [EMAIL&NBSP;PROtected] # Mailbox OrganizationName = XXX # organizationalunitname = XX X # # [Root_ca_extensions]basicconstraints = Ca:true

Generate CA root certificates and keys

export OPENSSL_CONF=~/myCA/caconfig.cnf       #该命令用于给环境变量 OPENSSL_CONF 赋值为caconfig.cnf。openssl req -x509 -newkey rsa:2048 -out cacert.pem -outform PEM -days 1825             # 生成 CA 根证书和密钥

This command requires the user to set a password. Don't forget.
The above steps generate the CA self-signed root certificate, and the RSA public/private key pair. The format of the certificate is PEM and is valid for 1825 days.

• /MYCA/CACERT.PEM:CA Root Certificate
• /MYCA/PRIVATE/CAKEY.PEM:CA private Key

Create server Public Private key

Build Server configuration file exampleserver.cnf

vim ~/myCA/exampleserver.cnf

EXAMPLESERVER.CNF file contents are as follows

## exampleserver.cnf#[ req ]prompt             = nodistinguished_name = server_distinguished_name[ server_distinguished_name ]commonName              = localhost          # 服务器域名stateOrProvinceName     = JS                 # 服务器所在省份countryName             = CN                 # 服务器所在国家（仅限2个字符）emailAddress            = [email protected]       # 邮箱organizationName        = XXX                # organizationalUnitName  = XXX                

Generate server certificates and keys

export OPENSSL_CONF =~/myCA/exampleserver.cnf   # 该命令设置环境变量 OPENSSL_CONF，使得 openssl 更换配置文件。openssl req -newkey rsa:1024 -keyout tempkey.pem -keyform PEM -out tempreq.pem -outform PEM

Similarly, you need to enter a passphrase.
After that, there are 2 types of operations on the temporary key, one of which can be selected
1. Convert the temporary private key to unencrypted key, that is, the secret key is not encrypted.

penssl rsa -in tempkey.pem -out server_key.pem

You need to enter a passphrase.

2. If you want to keep key in encrypted state, rename it directly

mv tempkey.pem server_key.pem

The difference between the two is that the second need to enter the private key when the server starts the passphrase, otherwise it will cause the server to fail, but the second security above the first, you can better protect the secret key.

Signing the server certificate with CA key

export OPENSSL_CONF=~/myCA/caconfig.cnfopenssl ca -in tempkey.pem -out server_crt.pem

Delete temporary certificates and password files

rm -f tempkey.pem && rm -f tempreq.pem

The self-signed server certificate and key pair are now generated:

• SERVER_CRT.PEM: Server certificate file
• SERVER_KEY.PEM: Server Key file

Configure Apache

Set up an SSL configuration file, lab-ssl.conf

vim /etc/apache2/sites-available/lab-ssl.conf

lab-ssl.conf file contents are as follows

<ifmodule mod_ssl.c> <virtualhost _default_:443> ServerAdmin [email protected] DocumentR Oot/var/www/lab # Site Directory # Available Loglevels:trace8, ..., Trace1, debug, info, notic        E, warn, # Error, Crit, alert, Emerg.        # It's also possible to configure the loglevel for particular # modules, e.g.         #LogLevel info ssl:warn errorlog ${apache_log_dir}/error.log customlog ${apache_log_dir}/access.log combined # for more configuration files from conf-available/, which is # enabled or disabled at a global level, it Is possible to # include a line for only one particular virtual host. For example the # following line enables the CGI configuration for this host only # after it has been global        Ly disabled with "a2disconf". #Include conf-available/serve-cgi-bin.conf # SSL Engine Switch: # enable/disable SSL for this virtual ho      St.  Sslengine on # A self-signed (snakeoil) certificate can is created by installing # The Ssl-cert packag E. See #/usr/share/doc/apache2/readme.        debian.gz for more info.        # If Both key and certificate are stored in the same file, only the # sslcertificatefile directive is needed. #SSLCertificateFile/etc/ssl/certs/ssl-cert-snakeoil.pem #SSLCertificateKeyFile/ETC/SSL/PRIVATE/SSL-CERT-SN Akeoil.key # Web site certificate and private key address Sslcertificatefile/home/libaoquan/myca/server_crt.pem Sslcertificatekeyfil E/HOME/LIBAOQUAN/MYCA/SERVER_KEY.PEM # server Certificate Chain: # point sslcertificatechainfile at a f  Ile containing the # concatenation of PEM encoded CA certificates which form the # certificate chain for The server certificate.  Alternatively # The referenced file can be a same as Sslcertificatefile # when the CA certificates is Directly appended to the server #  Certificate for convinience. #SSLCertificateChainFile/ETC/APACHE2/SSL.CRT/SERVER-CA.CRT # Certificate Authority (CA): # Set the CA C        Ertificate verification path where to find CA # certificates for client authentication or alternatively one # Huge file containing all of them (file must is PEM encoded) # Note:inside Sslcacertificatepath you need ha SH symlinks # to point to the certificate files.        Use the provided # Makefile to update the hash symlinks after changes. #SSLCACertificatePath/etc/ssl/certs/#SSLCACertificateFile/ETC/APACHE2/SSL.CRT/CA-BUNDLE.CRT # Certifica Te Revocation Lists (CRL): # Set The CA revocation path where to find CAs CRLs for client # Authenticatio N or alternatively one huge file containing all # of them (file must BES PEM encoded) # Note:inside SSLC Arevocationpath need Hash symlinks # to point to the Certificate files.        Use the provided # Makefile to update the hash symlinks after changes. #SSLCARevocationPath/etc/apache2/ssl.crl/#SSLCARevocationFile/ETC/APACHE2/SSL.CRL/CA-BUNDLE.CRL # Clien  T authentication (type): # Client Certificate Verification Type and depth.  Types is # None, optional, require and Optional_no_ca. Depth is a # number which specifies what deeply to verify the certificate # issuer chain before deciding        The certificate is not valid. #SSLVerifyClient require #SSLVerifyDepth # SSL Engine options: # Set various options for the        SSL engine.  # o Fakebasicauth: # Translate The client to a Basic authorisation.  This means, the standard Auth/dbmauth methods can is used for access control.        The # user name is the ' one line ' version of the client ' s certificate. # Note that no password is obtained froM the user.        Every entry in the user # file needs this password: ' Xxj31zmtzzkva '. # o Exportcertdata: # This exports, additional environment Variables:ssl_client_cert and # ssl_s Erver_cert. These contain the pem-encoded certificates of the # Server (always existing) and the client (only existing when Client # authentication is used).        This can is used to import the certificates # into CGI scripts.        # o Stdenvvars: # This exports the standard SSL/TLS related ' ssl_* ' environment variables. # Per Default this exportation are switched off for performance reasons, # Because the extraction step was an E Xpensive operation and is usually # useless for serving static content.        So one usually enables the # exportation for CGI and SSI requests only. # o Optrenegotiate: # This enables optimized SSL connection renegotiation handling when SSL # diRectives is used in per-directory context. #SSLOptions +fakebasicauth +exportcertdata +strictrequire <filesmatch "\. (cgi|shtml|phtml|php) $ "> ssloptions +stdenvvars </FilesMatch> <directory/usr/lib    /cgi-bin> ssloptions +stdenvvars </Directory> # SSL Protocol adjustments: # The safe and default but still SSL/TLS standard compliant shutdown # approach are that Mod_ssl sends the close Notify alert but doesn ' t wait for # The close notify alert from client. When you need a different shutdown # approach you can use one of the following variables: # o Ssl-unclea N-shutdown: # This forces a unclean shutdown when the connection is closed, i.e. no # SSL Close Notif  Y alert is the send or allowed to received. This violates # The SSL/TLS standard is needed for some brain-dead browsers. Use # This when you receive I/O ERrors because of the standard approach where # MOD_SSL sends the close notify alert.    # o Ssl-accurate-shutdown: # forces an accurate shutdown when the connection is closed, i.e. a # SSL Close Notify alert is a send and mod_ssl waits for the close notify # Alert of the client. This is 100% SSL/TLS standard compliant, but on # practice often causes hanging connections with brain-dead brow Sers.        Use # This is only for browsers where you know that their SSL implementation # works correctly. # notice:most Problems of broken clients is also related to the HTTP # keep-alive facility, so you usually ad Ditionally want to disable # Keep-alive for those clients, too.        Use variable ' nokeepalive ' for this. # Similarly, one have to force some clients to use http/1.0 to workaround # their broken http/1.1 implementation . Use variables "downgrade-1.0" and "#" Force-response-1.0 "for this. # browsermatch "MSIE [2-6]" # nokeepalive Ssl-unclean-shutdown # downgrade-1.0 force-response- 1.0 </virtualhost></ifmodule># Vim:syntax=apache ts=4 sw=4 sts=4 SR Noet

Start the SSL service

a2ensite /etc/apache2/sites-available/lab-ssl.confa2enmod ssl

See if the configuration is correct

Enter Https://localhost in the browser address bar

Discover the browser does not trust this site, why? The behavior of this site's certificate is signed with our own CA, and the browser does not trust our own CA, so we need to manually import the CA certificate to let the browser trust our ca.
The import steps are as follows:
Open the FireFox browser, select Edit----preferences----privacy and security----Certificate----View Certificate----Certificate Authority, click Import, select Root certificate "Cacert.pem" in the MyCA directory, import.
After that, browse localhost again

The Address bar has a green lock, and the HTTPS service is built.

Build an HTTPS server with a self-built CA certificate