diff --git a/webapps/docs/ssl-howto.xml b/webapps/docs/ssl-howto.xml index edb546d..58301d6 100644 --- a/webapps/docs/ssl-howto.xml +++ b/webapps/docs/ssl-howto.xml @@ -112,67 +112,47 @@ The theory behind this design is that a server should provide some kind of reasonable assurance that its owner is who you think it is, particularly before receiving any sensitive information. While a broader explanation of Certificates is beyond the scope of this document, think of a Certificate -as a "digital driver's license" for an Internet address. It states what -company the site is associated with, along with some basic contact -information about the site owner or administrator.
- -This "driver's license" is cryptographically signed by its owner, and is -therefore extremely difficult for anyone else to forge. For sites involved -in e-commerce, or any other business transaction in which authentication of -identity is important, a Certificate is typically purchased from a well-known -Certificate Authority (CA) such as VeriSign or Thawte. Such -certificates can be electronically verified -- in effect, the Certificate -Authority will vouch for the authenticity of the certificates that it grants, -so you can believe that the Certificate is valid if you trust the Certificate -Authority that granted it.
- -In many cases, however, authentication is not really a concern. An
-administrator may simply want to ensure that the data being transmitted and
-received by the server is private and cannot be snooped by anyone who may be
-eavesdropping on the connection. Fortunately, Java provides a relatively
-simple command-line tool, called keytool
, which can easily create
-a "self-signed" Certificate. Self-signed Certificates are simply user
-generated Certificates which have not been officially registered with any
-well-known CA, and are therefore not really guaranteed to be authentic at all.
-Again, this may or may not even be important, depending on your needs.
This certificate is cryptographically signed by its owner, and is +therefore extremely difficult for anyone else to forge. In order to for the +certificate to work in the visitors browsers without warnings it needs +to signed by a trusted third party, those are called Certificate Authorities (CA). +In order to obtain a signed certificate, you need to follow the instructions +of your CA. One good suggestion is to use Lets Encrypt as your CA, as they +don't charge money and lets you automate the retrieval of certificates.
+ +Java provides a relatively simple command-line tool, called
+keytool
, which can easily create a "self-signed" Certificate.
+Self-signed Certificates are simply user generated Certificates which have not
+been officially registered with any well-known CA, and are therefore not really
+guaranteed to be authentic at all. In normal operations, this kind of certificate
+shouldn't be used.
The first time a user attempts to access a secured page on your site, -he or she is typically presented with a dialog containing the details of -the certificate (such as the company and contact name), and asked if he or she -wishes to accept the Certificate as valid and continue with the transaction. -Some browsers will provide an option for permanently accepting a given -Certificate as valid, in which case the user will not be bothered with a -prompt each time they visit your site. Other browsers do not provide this -option. Once approved by the user, a Certificate will be considered valid -for at least the entire browser session.
- -Also, while the SSL protocol was designed to be as efficient as securely
-possible, encryption/decryption is a computationally expensive process from
-a performance standpoint. It is not strictly necessary to run an entire
-web application over SSL, and indeed a developer can pick and choose which
-pages require a secure connection and which do not. For a reasonably busy
-site, it is customary to only run certain pages under SSL, namely those
-pages where sensitive information could possibly be exchanged. This would
-include things like login pages, personal information pages, and shopping
-cart checkouts, where credit card information could possibly be transmitted.
-Any page within an application can be requested over a secure socket by
-simply prefixing the address with https:
instead of
-http:
. Any pages which absolutely require
-a secure connection should check the protocol type associated with the
-page request and take the appropriate action if https
is not
-specified.
When securing a website with SSL it's important to make sure that +all assets that the site uses are distributed over SSL, so that an attacker +can't bypass the security by injecting malicious content in a javascript file +or similar. In order to further enhance the security of your website +you should evaluate to use the HSTS header, it allows you to communicate +to the browser that your site should always be accessed over https.
Finally, using name-based virtual hosts on a secured connection can be -problematic. This is a design limitation of the SSL protocol itself. The SSL -handshake, where the client browser accepts the server certificate, must occur -before the HTTP request is accessed. As a result, the request information -containing the virtual host name cannot be determined prior to authentication, -and it is therefore not possible to assign multiple certificates to a single -IP address. If all virtual hosts on a single IP address need to authenticate +problematic as java didn't support Server Name Indication (SNI) until java 8. +With only legacy SSL support, the SSL handshake, where the client browser +accepts the server certificate, must occur before the HTTP request is accessed. +As a result, the request information containing the virtual host name cannot +be determined prior to authentication, and it is therefore not possible to +assign multiple certificates to a single IP address. With SNI the hostname is +transmitted before the handshake is completed, and it's therefore possible +to have virtual hosts. SNI is implemented in tomcat 9, but not in tomcat 8.
+ +If all virtual hosts on a single IP address need to authenticate against the same certificate, the addition of multiple virtual hosts should not interfere with normal SSL operations on the server. Be aware, however, that most client browsers will compare the server's domain name against the domain