as a "digital driver's license" for an Internet address.  It states what

as a security guarantee for an Internet domain.  It lets the visitors

company the site is associated with, along with some basic contact

of your website verify that the content actually originated from your

information about the site owner or administrator.</p>

servers, and didn't get modified by an attacker on the way.</p>

<p>This "driver's license" is cryptographically signed by its owner, and is

<p>This certificate is cryptographically signed by its owner, and is

therefore extremely difficult for anyone else to forge.  For sites involved

therefore extremely difficult for anyone else to forge.  In order to for the

in e-commerce, or any other business transaction in which authentication of

certificate to work in the visitors browsers without warnings it needs

identity is important, a Certificate is typically purchased from a well-known

to signed by a trusted third party, those are called <em>Certificate Authorities</em> (CA).

<em>Certificate Authority</em> (CA) such as VeriSign or Thawte.  Such

In order to obtain a signed certificate, you need to follow the instructions

certificates can be electronically verified -- in effect, the Certificate

of your CA. One good suggestion is to use Lets Encrypt as your CA, as they

Authority will vouch for the authenticity of the certificates that it grants,

don't charge money and lets you automate the retrieval of certificates.</p>

so you can believe that the Certificate is valid if you trust the Certificate

Authority that granted it.</p>

<p>Java provides a relatively simple command-line tool, called

<code>keytool</code>, which can easily create a "self-signed" Certificate.

<p>In many cases, however, authentication is not really a concern.  An

Self-signed Certificates are simply user generated Certificates which have not

administrator may simply want to ensure that the data being transmitted and

been officially registered with any well-known CA, and are therefore not really

received by the server is private and cannot be snooped by anyone who may be

guaranteed to be authentic at all. In normal operations, this kind of certificate

eavesdropping on the connection.  Fortunately, Java provides a relatively

shouldn't be used.</p>

simple command-line tool, called <code>keytool</code>, 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.</p>

<section name="General Tips on Running SSL">

<section name="General Tips on Running SSL/TLS">

<p>The first time a user attempts to access a secured page on your site,

<p>When securing a website with SSL it's important to make sure that

he or she is typically presented with a dialog containing the details of

all assets that the site uses are distributed over SSL, so that an attacker

the certificate (such as the company and contact name), and asked if he or she

can't bypass the security by injecting malicious content in a javascript file

wishes to accept the Certificate as valid and continue with the transaction.

or similar. In order to further enhance the security of your website

Some browsers will provide an option for permanently accepting a given

you should evaluate to use the HSTS header, it allows you to communicate

Certificate as valid, in which case the user will not be bothered with a

to the browser that your site should always be accessed over https.</p>

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.</p>

<p>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 <code>https:</code> instead of

<code>http:</code>.  Any pages which absolutely <strong>require</strong>

a secure connection should check the protocol type associated with the

page request and take the appropriate action if <code>https</code> is not

specified.</p>

problematic.  This is a design limitation of the SSL protocol itself.  The SSL

problematic as java didn't support Server Name Indication (SNI) until java 8.

handshake, where the client browser accepts the server certificate, must occur

With only legacy SSL support, the SSL handshake, where the client browser

before the HTTP request is accessed.  As a result, the request information

accepts the server certificate, must occur before the HTTP request is accessed.

containing the virtual host name cannot be determined prior to authentication,

As a result, the request information containing the virtual host name cannot

and it is therefore not possible to assign multiple certificates to a single

be determined prior to authentication, and it is therefore not possible to

IP address.  If all virtual hosts on a single IP address need to authenticate

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.</p>

<p>If all virtual hosts on a single IP address need to authenticate