This article describes how to configure SSL support in Tomcat.
1. It is easier to configure SSL support in Tomcat. There are several steps:
(1) If the JVM version is earlier than 1.3, You need to download JSSE, which is a Java SSL support library. Since JDK 1.4, JSSE has been built into JDK. Therefore, this step can be omitted.
(2) execute the command (in Linux ):
$ Java_home/bin/keytool-genkey-alias tomcat-keyalg RSA
The same is true in windows, where a forward slash is used for the path.
Through this command, a file named. keystore is generated under the current user's home directory, which is the CA certificate file used for Tomcat SSL. When executing the preceding command, enter some information, such as the company name and organization name. The key is to enter two passwords. The first password must be entered at the beginning. Tomcat will use this password to encrypt the transmitted information, tomcat considers this password as "changeit" by default. We can choose not to set this password. If it is not set as this password, it will be on the server. when configuring SSL in XML, We need to configure the password we set. The second password that will be asked is private keystore password, which is used to encrypt the certificate itself, that is, a password that distinguishes the certificate from other certificates. Please note that Tomcat tells us that the password must be exactly the same as the first Password, otherwise Tomcat will report an error. So when you enter the second password, press enter to set it to the same as the first password.
(3) configure the SSL-related ctor in server. xml. By default, the connector configuration is commented out and opened. Then, my configuration here is as follows:
<! -- Define a ssl http/1.1 Connector on port 443 -->
<Connector Port = "443" maxhttpheadersize = "8192"
Maxthreads = "150" minsparethreads = "25" maxsparethreads = "75"
Enablelookups = "false" disableuploadtimeout = "true"
Acceptcount = "100" Scheme = "HTTPS" secure = "true"
Clientauth = "false" keystorepass = "jofoeasycluster" sslprotocol = "TLS"/>
From the above configuration, we can see that first, I changed the SSL port to standard 443, and Tomcat's default value is 8443 (because the port earlier than 1024 is not available to the root user, in our EC, Tomcat must be started by the root user), so that the user can directly input "jofoeasycluster", which is generated by me. the password entered when the keystore file is used. Some other common configurations are listed in this document. See the table in appendix 1. For example, if we do not place the. keystore file in the user's home directory of the user who started tomcat, we need to set the keystorefile attribute. This includes the clientauth value, which is set to false, that is, the client does not need to provide a certificate, but the client only needs to accept our certificate.
In this way, the configuration is complete, and in my tomcat configuration, I commented out the connector that originally worked on port 8080 for non-SSL, in this way, the user cannot access non-ssl ec. In tomcat, you can define multiple ctor S. Tomcat itself has many connector S, which are used for SSL, common, and port 8009 connector, which are used for AJP, and so on.
With the above configuration, our easycluster can run on SSL without modifying any code. The disadvantage of this solution is that, because the SSL-based HTTP protocol requires server-side encryption during data transmission, which is then sent to the client and decrypted by the client. For the server, the load is heavy, because the SSL encryption algorithm is still intensive. Therefore, the common practice is that SSL is not used for every page in the Web application, but only for some pages involving sensitive data.
However, for EC, this method is a bit problematic because EC is based on Struts. Therefore, all links and form forms are submitted using the struts mechanism, that is to say, we do not need to write a complete URL. We only need to give a relative address, so we have no chance to manually set whether the link is HTTP or HTTPS in the code.
For this question, we have a dedicated struts extension to do this, which can be found in Google Search "struts SSL", which is also officially recommended by struts. This extension will add and modify some TLD and some classes. After the extension is installed, we can use the tag library and action config, add a secure = true/false configuration to specify whether the action/link uses https or HTTP.
At present, we do not consider the extension above, because for EC, the access traffic is not very large, and the high-performance computing server is basically very powerful, so we will not consider it for the moment. But remember, there are solutions.
OK. As described above, we can run Tomcat on SSL, but this document also provides a good introduction to some SSL background knowledge. I think it is very valuable, so I made notes here. Understanding these background knowledge is also very helpful for understanding some of the above configuration items.
1. SSL introduction. We all know that the most common purpose of SSL is to encrypt the transmitted data. When running SSL on both the server and client, any data transmission and receiving process is decrypted/encrypted, ensuring the security of data transmission. But more importantly, SSL also has an authentication function. Specifically, when we request a secure connection, the server will first send a certificate (certificate) to our browser, we can clearly know the owner of the website and some relevant information, so that the client can know whether the website we are visiting is what we expect. Secondly, in some cases, server may also require the client to provide a certificate to prove the identity of the client. This function is very important for B2B websites, because either client or server, you need to clearly know the identity of the other party, which is called "client authentication ". That is why clientauth = true/false/want is used in the preceding configuration. Of course, in general, most servers do not require the client to provide certificates, because we only need an encrypted data transmission channel and do not need to verify the client.
2. A server must have an SSL certificate, that is, the certificate mentioned above for the client. This document interprets this certificate as "Digital driver's license ". In addition, the entire certificate must be secure, authoritative, and difficult to crack (otherwise, criminals can forge the certificate ). Therefore, from a formal perspective, a commercial SSL server needs to purchase a certificate from a third-party organization (Certificate Authority, CA). Ca ensures the security and reliability of the certificate, then, as long as the client trusts the CA, it can trust the certificate. Famous CAs include Verisign and thawte. However, for us, this is obviously unnecessary, because we do not have that high security requirements, so we have tools like keytool, this tool allows us to generate a self-signed certificate ourselves. Although this certificate is not secure and reliable as those issued by the CA, It is enough. OK. When we use this certificate, we can explain why we are visiting some SSL websites. ie will pop up a window saying that the certificate is not verified, there may be risks in such a dialog box, because this certificate is not from CA and is self-signed by ourselves. If we trust this certificate, as long as the IE window is not closed, this box will not pop up for future operations. However, once IE is closed, we will re-open IE to access this website, this box will pop up again. To this end, ie also provides the certificate saving function. If we save this certificate to a local device, this box will no longer pop up when you visit this website. Of course, some browsers do not provide the certificate saving function, so this box pops up every time.
3. The keystore generated using the keytool provided by JDK is called a jks certificate, which is made by Java itself. In addition, there are keystores in pkcs11 and PKCS12 formats. Certificates in these formats must be generated using software such as OpenSSL and Microsoft key manager.
4. the second half of this article explains how to install a certificate from CA and configure tomcat to use this certificate. If necessary, you can refer to it.
5. In the above configuration, when we use keytool to generate a certificate, there is an option called-alias tomcat, which adds an alias to the certificate to distinguish multiple certificates. The alias named Tomcat is also the default value of Tomcat. That is to say, Tomcat considers the certificate alias found by default as Tomcat. If we modify this alias, do not forget the server in Tomcat. configure in XML.
6. if we modify the default port number (8443) When configuring SSL in Tomcat, do not forget to modify the redirectport attribute value in non-SSL ctor at the same time, this redirectport indicates the port number used to switch from a non-SSL connection to an SSL connection. Of course, in the above configuration, we commented out the non-SSL connector.
7. At the end of this article, there is a troubleshooting. If you encounter any problems when configuring Tomcat over SSL, you may wish to find the answer here.
8. At the end of this article, we provide a useful thing, that is, how to obtain the session ID during SSL. The method is a little different from that during non-ssl. The Code should be written as follows:
String sslid = (string) request. getattribute ("javax. servlet. Request. ssl_session ");
If you have any questions, please read this document. It's a good one.
