HTTPD set HTTPS two-way authentication

Last year, the use of Tomcat, JBoss configured HTTPS two-way authentication, when the main use of the JDK with the Keytool tool. This time with httpd + OpenSSL, the difference is larger

Search on the Internet a lot of articles, found that the overall introduction is not much, or the version is older. So the process of my configuration is recorded completely for reference

First of all, the content of HTTPS involved is very complex, including a variety of terminology, commands, algorithms, I do not fully understand now. This article will try to explain what I know, but the depth of the content, temporarily do not intend to delve into the

First, the environment

httpd:2.4.4
openssl:1.0.1
Os:ubuntu 12.04 LTS

Second, the scene

I'm going to configure an HTTPS two-way authentication on the httpd to both identify myself to the client and allow only specific clients to access it. This article is mainly about the role of the server as a configuration, as a client configuration, the end will be a bit, but will not specify

Generally speaking, the Internet station will not configure two-way authentication, because the client certificate distribution and management will be more troublesome, will put the user outside the door, so generally can not do so. Of course, such as banks and other high security requirements of the site, will also use two-way certification, such as U shield, security controls, what is in fact, the curing of the client certificate

But for enterprise applications, customers are generally fixed, such as two known systems docking, internal system integration and so on. So in the enterprise application domain, two-way authentication is still more common

Third, background knowledge

The certificate (certificate) is the core of HTTPS, but in fact the certificate is not a single thing, but a combination of several technologies

For the safety of network transmission, there are many kinds of technology, the main is the following 3 kinds:

1, encryption/decryption

Avoid message plaintext transmission and encrypt messages. The early days are generally symmetric encryption algorithms, now generally asymmetric encryption, the most common algorithm is RSA. In the following introduction, you will see the word RSA many times

2. Message Digest

This technique is primarily designed to avoid tampering with messages. A message digest is a piece of information, through some algorithm, to draw a string of strings. This string is the digest of the message. If the message is tampered with (changed), then the digest is bound to change, as is often the case. If 2 different message-generated summaries are the same, then this is called a collision.

The algorithm of message digest mainly has MD5 and Sha, in the domain of the certificate, it is generally the SHA (Secure hashing algorithm)

3. Digital signature

Digital signature is to verify the identity of both sides, to avoid identity forgery

The above three technologies are combined, which are widely used in HTTPS (certificate), the certificate itself carries the encryption/decryption information, and can identify its own identity, also bring the message digest

Iv. configuring one-way HTTPS in httpd

First, in the%httpd_home%/conf/directory, modify the httpd.conf file, load the necessary modules
httpd code LoadModule socache_shmcb_module modules/mod_socache_shmcb.so LoadModule socache_dbm_module socache_dbm.so LoadModule socache_memcache_module modules/mod_socache_memcache.so LoadModule ssl_module Ssl.so

LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
LoadModule socache_dbm_module Modules/mod_socache _dbm.so
LoadModule socache_memcache_module modules/mod_socache_memcache.so
LoadModule ssl_module Mod_ssl.so

The premise here is that the SSL module has been compiled when the httpd is compiled. This step looks at another document:
http://kyfxbl.iteye.com/blog/1902299

Then import the default SSL profile, and of course you can choose not to import it and configure it directly in httpd.conf. However, importing the default can save a lot of time, and the default file is configured with Vhost and does not conflict with main server, which can be considered a best practice
httpd Code # Secure (SSL/TLS) connections Include conf/extra/httpd-ssl.conf <ifmodule ssl_module> Eed startup builtin Sslrandomseed connect builtin </IfModule>

# Secure (SSL/TLS) connections
Include conf/extra/httpd-ssl.conf

<ifmodule ssl_module>
Sslrandomseed startup builtin
sslrandomseed connect builtin
</IfModule>

Then open the%httpd_home%/conf/extra/directory, look at the httpd-ssl.conf, mainly with the following configuration
httpd code sslengine on Sslcertificatefile "/usr/local/httpd/conf/server.cer sslcertificatekeyfile"/usr/local/httpd/c Onf/server.key.pem "#SSLCACertificateFile"/usr/local/httpd/conf/ca.cer "#SSLVerifyClient require #SSLVerifyDepth 1 0

Sslengine on
sslcertificatefile "/usr/local/httpd/conf/server.cer"
sslcertificatekeyfile "/usr/local/ Httpd/conf/server.key.pem "
#SSLCACertificateFile"/usr/local/httpd/conf/ca.cer "
#SSLVerifyClient require
#SSLVerifyDepth  10

As long as the top 3, one-way HTTPS authentication is configured well. The next 3 are currently commented out, is a two-way authentication after the use of

Then restart the httpd and you will find an error:

Ah00526:syntax error on line of/usr/local/httpd/conf/extra/httpd-ssl.conf:
Sslcertificatefile:file '/usr/local/httpd/conf/server.cer ' does not exist or are empty

This is because HTTPD requires a server-side private key (. Key.pem), and a server-side certificate (. cer). The path to these 2 files has been configured previously, but has not yet been created. The next step is to create these files

V. Creating a CA (Certificate authority)

This CA, also known as "Root certificate"

The server has made a certificate, but this is no legal effect, who can do their own certificates, it is not to achieve the goal of security. So there will be an organization responsible for confirming the identity of the server and then issuing a unified certificate. So we can have authority.

When a browser accesses a Web site via the HTTPS protocol, the site first sends a certificate of its own (certificate). The browser then goes to the Authority (CA) to verify that the certificate was issued by it. If so, trust the site's certificate and continue to visit, and if not, how to deal with it depends on the implementation. A General browser pops up a warning and lets the user decide whether or not to continue the visit. Of course, direct rejection is okay.

Now there are 3 major CAs in the world, if you want to do a website, as mentioned above, generally need to ask these authorities to help issue certificates. Now all mainstream browsers, by default, have installed the root certificates of these CAs, so if the site's certificate is issued by these authorities, the browser will not issue a warning. For example Alipay, its certificate is issued by VeriSign, so visit Alipay, the browser will not issue a warning



There is also a chain of relationships, such as I have 10 subsites, if each have to go to the CA to issue certificates, it is very troublesome. I can find a CA to issue a secondary root certificate to me, and then use this secondary root certificate to issue 10 certificates to myself. So as long as the customer's browser has a CA root certificate can be, these 10 certificates can be authenticated, do not require the client to install secondary root certificate, the original see below:

Reference intermediate CA certificates lie between the root CA certificate (which is installed in the browsers) and the server CE Rtificate (which you installed on the server).

If it is an enterprise application, that's all you can do to yourself as a CA, because you can ask the target user (System) to install their own CA root certificate, the effect is the same, you can also save the authority to issue a certificate to the CA fee (Internet applications to distribute their own CAs to countless Internet users, very difficult)

Here's how to create your own CA

1. Preparation work

First in a random directory, create the following subdirectories:
/private
/certificates

Where private is the private key and CSR (described later), certificates is in the certificate

2. Create CA private key
OpenSSL code OpenSSL genrsa-aes256-out PRIVATE/CA.KEY.PEM 2048

OpenSSL genrsa-aes256-out Private/ca.key.pem 2048

The final parameter is the length of the RSA key, which defaults to 512. 2048 actually a bit longer, the old browser will not support later, but now the mainstream browser is supported, so the problem is not

With this command, the private key is created, and the filename is Ca.key.pem

With this command, you can look at the information about the private key that you just created.
OpenSSL code OpenSSL rsa-noout-text-in Private/ca.key.pem

OpenSSL rsa-noout-text-in Private/ca.key.pem

But basically, look is also white look, anyway, I can not understand. Only know the private key in fact there are 2 sets of numbers, is used to form a public key, and finally will be included in the certificate

Reference
A private key contains a series of numbers. Two of these numbers form the ' public key ', the others are part of the "private key". The ' public key ' bits are included when you are generate a CSR, and subsequently form part of the associated certificate.


In addition, the final. Pem extension means that the private key is encoded in PEM. In fact, both the private key and the certificate are encoded in PEM, and the PEM is just a coded format that doesn't require much attention. HTTPD can handle this encoding format directly, but browsers and Java are not available, so when needed, the code is changed from a PEM to a PKCS, which is described later. As long as you know the certificate and the private key are encoded, just the code is a PEM or a PKCS difference. It's like "hello." You can use UTF-8 encoding, or you can use the GBK code, the content is unchanged

3. Create CA Signature Request
OpenSSL code OpenSSL req-new-key private/ca.key.pem-out private/ca.csr-subj "/c=cn/st=sz/l=sz/o=kyfxbl/ou=kyfxbl/cn=*. Kyfxbl.net "

OpenSSL req-new-key private/ca.key.pem-out private/ca.csr-subj "/c=cn/st=sz/l=sz/o=kyfxbl/ou=kyfxbl/cn=*. Kyfxbl.net "

Note here that if you do not use the-SUBJ parameter, you will enter the identity information for the issuing target at the command-line interaction, called DN (distinguished name). It does not matter, the most important is the CN line, because I am here is the root certificate, so I set to *.kyfxbl.net, so I later use this CA issued www.kyfxbl.net, game.kyfxbl.net, news.kyfxbl.net ... , it's all valid.

The generated signature request file is CA.CSR
OpenSSL code OpenSSL req-noout-text-in PRIVATE/CA.CSR

OpenSSL req-noout-text-in PRIVATE/CA.CSR

Ditto, can't read

4, the issue of their own CA root certificate
OpenSSL code OpenSSL x509-req-days 3650-sha1-extensions v3_ca-signkey private/ca.key.pem-in private/ca.csr-out Certi Ficates/ca.cer

OpenSSL x509-req-days 3650-sha1-extensions v3_ca-signkey private/ca.key.pem-in private/ca.csr-out Er

Here the parameter is very complex, I also do not quite know exactly meaning what, can use OpenSSL x509-help oneself to study

The resulting ca.cer is the ultimate root certificate. This file is important because subsequent server-side certificates, client certificates, are issued by this CA, and distributed to customers for import into their own browsers or systems.

The commands to view are:
OpenSSL code OpenSSL x509-noout-text-in certificates/ca.cer

OpenSSL x509-noout-text-in Certificates/ca.cer

5. Convert the root certificate from PEM code to PKCS

This step is not necessarily optional, but as mentioned earlier, the Java environment is not directly encoded with a PEM certificate, and many browsers do not, so sometimes you need to turn the code
OpenSSL code OpenSSL pkcs12-export-cacerts-inkey private/ca.key.pem-in certificates/ca.cer-out certificates/ca.p12

OpenSSL pkcs12-export-cacerts-inkey private/ca.key.pem-in certificates/ca.cer-out certificates/ca.p12

The resulting ca.p12 is the CA root certificate after the transcoding, when the ca.cer can not be used directly, the CA.P12 instead

Vi. issuing service-side certificates

Now that both the CA root certificate and the private key are available, you can start issuing a service-side certificate (the issuing request CA.CSR is a process file, which is no longer needed if you have a CER, and you can delete it as well). The following command is similar to issuing CA certificates, but there are differences in parameters

1. Create a service-side private key
OpenSSL code OpenSSL genrsa-aes256-out PRIVATE/SERVER.KEY.PEM 2048

OpenSSL genrsa-aes256-out Private/server.key.pem 2048

2. Create a service-side certificate issuance request
OpenSSL code OpenSSL req-new-key private/server.key.pem-out private/server.csr-subj "/c=cn/st=sz/l=sz/o=kyfxbl/ou=kyfx Bl/cn=www.kyfxbl.net "

OpenSSL req-new-key private/server.key.pem-out private/server.csr-subj "/c=cn/st=sz/l=sz/o=kyfxbl/ou=kyfxbl/cn= Www.kyfxbl.net "

And CA.CSR is the difference is that the CN here is not *.kyfxbl.net, but www.kyfxbl.net, because I am now in the www.kyfxbl.net to apply for a certificate

3, the use of CA root certificate, issuing service-side certificate
OpenSSL code OpenSSL x509-req-days 3650-sha1-extensions v3_req-ca Certificates/ca.cer-cakey ial ca.srl-cacreateserial-in private/server.csr-out Certificates/server.cer

OpenSSL x509-req-days 3650-sha1-extensions v3_req-ca certificates/ca.cer-cakey private/ca.key.pem-caserial CA.SRL- Cacreateserial-in Private/server.csr-out Certificates/server.cer

Here and in front of the issuing CA certificate, the parameter difference is relatively large, the final server.cer, is the service-side certificate

Seven, test one-way certification

Copy the Server.key.pem and server.cer to the%httpd_home%/conf/directory, and then restart HTTPD, and you will be asked to enter a password



Then visit http://localhost:443/, you will report 400 errors:



Next use https://localhost:443 to access, browser alarm:



This is the previous creation of a CSR, the input of the role of CN, this certificate is for the Www.kyfxbl.net application, where the requested address is localhost, do not match so the error. In order to be able to use www.kyfxbl.net this host name to access, you need to change the/etc/hosts file:

127.0.0.1 localhost
192.168.1.102 www.kyfxbl.net

Then you can use Www.kyfxbl.net to visit, and try again: https://www.kyfxbl.net/

This browser is still an alarm, but the alarm information has changed:



The certificate information is as follows:



You can see that this certificate was issued by *.kyfxbl.net, which is not recognized by the browser, and therefore does not trust all certificates issued by this CA. Next you need to import ca.cer into your browser. It is also possible to import server.cer directly here, but if you create a Web site such as Www2.kyfxbl.net, then you can't. So the best way is to import the CA root certificate directly, then as long as the certificate issued by this root certificate, the browser will trust

Before import:



After import:



Visit again, you can see the success, the browser does not alarm, and the URL bar in front of a green hook



Eight, configure two-way authentication

If you want to configure the server to allow only legitimate user access, you need to configure two-way authentication

After the configuration for two-way authentication, in addition to the server to send a certificate to the client, the client will also send the client certificate to the server, the service-side certification passed, to allow access

httpd code Sslcacertificatefile "/usr/local/httpd/conf/ca.cer" sslverifyclient require sslverifydepth 10

Sslcacertificatefile "/usr/local/httpd/conf/ca.cer"
sslverifyclient require
sslverifydepth  10

On the basis of single authentication, the above 3 parameters are configured again.

Sslcacertificatefile, this means that when the client sends a client certificate, HTTPD uses which CA root certificate to verify it

Configuration is not yet restarted because the client certificate is not ready yet

Here's how the client certificate came in.

There are 2 different ways:

First, the client also has its own CA, and then issues the certificate to itself. The client's CA root certificate is sent over and configured as Sslcacertificatefile. This is basically impossible in Internet applications, and security and management are problems. But in enterprise applications, or more common, the two sides exchanged the CA root certificate

The second, with just the server-side CA root certificate, issued a client certificate, sent to the user, the user each time using this certificate to send requests, such as banks, Alipay and so on, in this way

Of course, theoretically there is a way, is the client to find the authority of the CA visa book, but this is not possible, because it is troublesome to find a CA sign is very expensive

The 2nd method is used in this article. are actually the same. The key is still on the CA root certificate, so as mentioned earlier, the CA root certificate is very important

IX. Issuance of client certificates

1. Create Client private key
OpenSSL code OpenSSL genrsa-aes256-out PRIVATE/CLIENT.KEY.PEM 2048

OpenSSL genrsa-aes256-out Private/client.key.pem 2048

2. Create a client certificate issuance request
OpenSSL code OpenSSL req-new-key private/client.key.pem-out private/client.csr-subj "/c=cn/st=sz/l=sz/o=kyfxbl/ou=kyfx BL/CN=KYFXBL "

OpenSSL req-new-key private/client.key.pem-out private/client.csr-subj "/c=cn/st=sz/l=sz/o=kyfxbl/ou=kyfxbl/cn= KYFXBL "

The difference here is that the CN here is not *.kyfxbl.net, not www.kyfxbl.net, just fill out a kyfxbl, or simply call the user is no problem, anyway, is a client certificate

3. Use CA root certificate to issue client certificate
OpenSSL code OpenSSL x509-req-days 3650-sha1-extensions v3_req-ca Certificates/ca.cer-cakey ial ca.srl-cacreateserial-in private/client.csr-out Certificates/client.cer

OpenSSL x509-req-days 3650-sha1-extensions v3_req-ca certificates/ca.cer-cakey private/ca.key.pem-caserial CA.SRL- Cacreateserial-in Private/client.csr-out Certificates/client.cer

This is basically the same as issuing server.cer.

4. Convert the client certificate into P12 format
OpenSSL code OpenSSL pkcs12-export-clcerts-inkey private/client.key.pem-in certificates/client.cer-out certificates/cl Ient.p12

OpenSSL pkcs12-export-clcerts-inkey private/client.key.pem-in certificates/client.cer-out certificates/client.p12

This step is necessary because the client certificate will need to be imported into the browser at a later time, but the generic browser cannot directly use a PEM-encoded certificate

Ten, Test two-way authentication

Copy the Ca.cer to the%httpd_home%/conf/directory and restart HTTPD

And then visit https://www.kyfxbl.net/again, the result is not a warning, but a direct error: