|
|
 |  |
|
|
When you are using Resin as a servlet runner behind another web
server, such as Apache or IIS, the web server is responsible for
handling SSL. The request looks like a regular unencrypted request to
Resin.
In a similar fashion, a hardware accelerator is sometimes used to
boost the performance of a server supporting SSL. This causes the
incoming requests to look like regular unencrypted requests to
Resin.
Even if you're using Apache/IIS for SSL support, you can still use
Resin's standalone web server for non-SSL pages. Your resin.conf will
need to list both a <http port='80'/> and a <srun port='6802'/>.
SSL provides two kinds of protection, encryption and server
authentication.
A set of bytes used to encrypt data and verify signatures.
The key is public because it can be made available without a loss of security.
The public key can only be used for encryption; it cannot decrypt
anything. A public key always has a corresponding private key.
SSL provides encryption of the data traffic betweeen a client and a server.
When the traffic is encrypted, an interception of that traffic will not reveal
the contents because they have been encrypted - it will be unusable
nonsense.
A set of bytes used to decrypt data and generate signatures.
The key is private because it must be kept secret or there will be a loss of
security. The private key is used for decryption of data that has been
encrypted with the corresponding public key.
SSL uses public key cryptography. Public key cryptography is based upon a
pair of keys, the public key and the private key. The public key is used to
encrypt the data. Only the corresponding private key can successfully decrypt
the data.
For example, when a browser connects to Resin, Resin provides the browser a
public key. The browser uses the public key to encrypt the data, and Resin
uses the private key to decrypt the data. For this reason, it is important that
you never allow anyone access to the private key, if the private key is
obtained by someone then they can use it to decrypt the data traffic.
Encryption is arguably the more important of the security meausures that SSL
provides.
A combination of a private key, identity information (such as company
name), and a signature generated by a signing authority.
private key.
SSL also provides the ability for a client to verify the identity of a server.
This is used to protect against identity theft, where for example a malicious
person imitates your server or redirects client traffic to a different server
while pretending to be you.
A company that is trusted to sign certificates. Browsers include
certificates of signing authorities that they trust.
Server authentication uses the signature aspect of public key cryptography.
The private key is used to sign messages, and the public key is used to verify
the signature. With SSL, the validity of signatures depends upon signing
authorities. Signing authorites (also called certificate authorities) are
companies who have generated public keys that are included with browser
software. The browser knows it can trust the signing authority, and the
signing authority signs your SSL certificate, putting its stamp of approval on
the information in your certificate.
Another name for signing authority. A company that is trusted to
sign certificates. Browsers include certificates of signing authorities that
they trust.
For example, after you generate your public and private key, you then
generate a signing request and send it to a signing authority. This signing
request contains information about your identity, this identity information is
confirmed by the signing authority and ultimately displayed to the user of the
browser. The signing authority validates the identity information you have
provided and uses their private key to sign, and then returns a
certificate to you. This certificate contains the identity information
and your public key, verified by the signing authority, and is provided to the
browser. Since the browser has the public key of the signing authority, it can
recognize the signature and know that the identity information has been
provided by someone that can be trusted.
OpenSSL is the same SSL implementation that Apache's mod_ssl
uses. Since OpenSSL uses the same certificate as Apache, you can get
signed certificates using the same method as for Apache's mod_ssl or
following the OpenSSL instructions.
On Unix systems, Resin's libexec/libresinssl.so JNI library
supports SSL using the
OpenSSL libraries.
Although the ./configure script will detect many configurations,
you can specify the openssl location directly:
resin> ./configure --with-openssl=/usr/local/ssl
On Windows systems, the resinssl.dll includes JNI code to use
OpenSSL libraries (it was in resin.dll in versions before 3.0). All
you need to do is to obtain an OpenSSL binary distribution and install
it.
Resin on Windows is compiled against the GnuWin32 binary, you can obtain an
installation package
here.
Once you have run the installation package, you can copy the necessary
dll libraries into $RESIN_HOME:
C:\> cd %RESIN_HOME%
C:\resin-3.0> copy "C:\Program Files\GnuWin32\bin\libssl32.dll" .\libssl32.dll
C:\resin-3.0> copy "C:\Program Files\GnuWin32\bin\libeay32.dll" .\libeay32.dll
You can make a keys/ subdirectory of $RESIN_HOME to do
your work from and as a place to store your generated keys.
unix> cd $RESIN_HOME
unix> mkdir keys
unix> cd keys
win> cd %RESIN_HOME%
win> mkdir keys
win> cd keys
Using OpenSSL requires a configuration file. Unix users might find
the default configuration file in /usr/ssl/openssl.cnf
or /usr/share/ssl/openssl.cnf. Windows users may not
have received one with their package.
Either way, it can be valuable to make your own
openssl.cnf that is used just for generating the keys to
use with Resin. You can use the following as a template for a file
$RESIN_HOME/keys/openssl.cnf. You may want to fill in
the _default values so you don't have to type them in
every time.
[ req ]
default_bits = 1024
distinguished_name = req_distinguished_name
[ req_distinguished_name ]
C = 2 letter Country Code, for example US
C_default =
ST = State or Province
ST_default =
L = City
L_default =
O = Organization Name
O_default =
OU = Organizational Unit Name, for example 'Marketing'
OU_default =
CN = your domain name, for example www.hogwarts.com
CN_default =
emailAddress = an email address
emailAddress_default =
Create a private key for the server. You will be asked for a
password - don't forget it! You will need this password anytime you
want to do anything with this private key. But don't pick something
you need to keep secret, you will need to put this password in the
Resin configuration file.
unix> openssl genrsa -des3 -out gryffindor.key 1024
win> "C:\Program Files\GnuWin32\bin\openssl.exe" \
genrsa -des3 -out gryffindor.key 1024
OpenSSL works by having a signed public key that corresponds to your
private key. This signed public key is called a certificate. A
certificate is what is sent to the browser.
You can create a self-signed certificate, or get a certificate that
is signed by a certificate signer (CA).
You can create a certificate that is self-signed, which is good for
testing or for saving you money. Since it is self-signed, browsers will not
recognize the signature and will pop up a warning to browser users. Other than
this warning, self-signed certificates work well. The browser cannot confirm
that the server is who it says it is, but the data between the browser and the
client is still encrypted.
unix> openssl req -config ./openssl.cnf -new -key gryffindor.key \
-x509 -out gryffindor.crt
win> "C:\Program Files\GnuWin32\bin\openssl.exe" req -config ./openssl.cnf \
-new -key gryffindor.key -x509 -out gryffindor.crt
You will be asked to provide some information about the identity of
your server, such as the name of your Organization etc. Common Name
(CN) is your domain name, like: "www.gryffindor.com".
To get a certificate that is signed by a CA, first you generate a
certificate signing request (CSR).
unix> openssl req -new -config ./openssl.cnf -key gryffindor.key \
-out gryffindor.csr
win> "C:\Program Files\GnuWin32\bin\openssl.exe" req -new \
-config ./openssl.cnf -key gryffindor.key -out gryffindor.csr
You will be asked to provide some information about the identity of
your server, such as the name of your Organization etc. Common Name
(CN) is your domain name, like: "www.gryffindor.com".
Send the CSR to a certificate signer (CA). You'll use the CA's
instructions for Apache because the certificates are identical. Some
commercial signers include:
You'll receive a gryffindor.crt file.
Most browsers are configured to recognize the signature of signing
authorities. Since they recognize the signature, they will not pop up a
warning message the way they will with self-signed certificates. The browser
can confirm that the server is who it says it is, and the data between the
browser and the client is encrypted.
The OpenSSL configuration has two tags and
. These correspond exactly to mod_ssl's
SSLCertificateFile and SSLCertificateKeyFile. So you can use the same
certificates (and documentation) from mod_ssl for Resin.
The full set of parameters is in the port configuration.
...
<http port="443">
<openssl>
<certificate-file>keys/gryffindor.crt</certificate-file>
<certificate-key-file>keys/gryffindor.key</certificate-key-file>
<password>my-password</password>
</openssl>
</http>
Once you have SSL configured, you can come back to this page using
an https:// style URL instead of an http://
url and you will get a message telling that SSL is working.
A quick test is the following JSP.
Secure? <%= request.isSecure() %>
The openssl tool can be used as a client, showing some interesting information
about the conversation between the client and the server:
unix$ openssl s_client -connect www.some.host:443 -prexit
A certificate chain is used when the signing authority is not an
authority trusted by the browser. In this case, the signing authority uses a
certificate which is in turn signed by a trusted authority, giving a chain of
[your certificate] <--- signed by ---- [untrusted signer] <---- signed by ---- [trusted signer].
The Resin config parameter is used to
specify a certificate chain. It is used to reference a file that is a
concatenation of:
- your certificate file
- the intermediate (untrusted) certificate
- the root (trusted) certificate.
The certificates must be in that order, and must be in PEM format.
Comodo (http://instantssl.com) is a signing
authority that is untrusted by most browsers. Comodo has their certificate
signed by GTECyberTrust.
Comodo gives you three certificates:
your_domain.crt (signed by Comodo)
ComodoSecurityServicesCA.crt (signed by GTE CyberTrust)
GTECyberTrustRoot.crt (universally known root)
In addition to this, you have your key, your_domain.key.
The contents of the file referred to by is a concatenation of the three
certificates, in the correct order.
$ cat your_domain.crt ComodoSecurityServicesCA.crt GTECyberTrustRoot.crt > chain.txt
<http port="443">
<openssl>
<certificate-key-file>keys/your_domain.key</certificate-key-file>
<certificate-file>keys/your_domain.crt</certificate-file>
<certificate-chain-file>keys/chain.txt</certificate-chain-file>
<password>test123</password>
</openssl>
</http>
We recommend avoiding JSSE if possible. It is slower than using
Resin's OpenSSL support and does not appear to be as stable as Apache
or IIS (or Netscape/Zeus) for SSL support. In addition, JSSE is far
more complicated to configure. While we've never received any problems
with Resin using OpenSSL, or SSL from Apache or IIS, JSSE issues are
fairly frequent.
This section gives a quick guide to installing a test SSL
configuration using Sun's JSSE. It avoids as many complications as
possible and uses Sun's keytool to create a server certificate.
Resin's SSL support is provided by Sun's
JSSE. Because of
export restrictions, patents, etc, you'll need to download the JSSE
distribution from Sun or get a commercial JSSE implementation.
More complete JSSE installation instructions for JSSE are at
http://java.sun.com/products/jsse/install.html.
- First download Sun's JSSE.
- Uncompress and extract the downloaded file.
- Install the JSSE jar files: jsse.jar, jnet.jar, and jcert.jar. You can
either put them into the CLASSPATH or you can put them into $JAVA_HOME/jre/lib/ext. Since you will use "keytool" with the new jars, you need to make them
visible to keytool. Just adding them to resin/lib is not enough.
- Register the JSSE provider (com.sun.net.ssl.internal.ssl.Provider).
Modify $JAVA_HOME/jre/lib/security/java.security so it contains something like:
security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.net.ssl.internal.ssl.Provider
Adding the JSSE provider allows "keytool" to create a key using the RSA
algorithm.
The server certificate is the core of SSL. It will identify your server and
contain the secret key to make encryption work.
- Sun's keytool
- A self-signed certificate using open_ssl
- A test certificate from Thawte
- A production certificate from one of the certificate authorities (Verisign, Thawte, etc)
In this case, we're using Sun's keytool to generate the
server certificate. Here's how:
resin1.2.b2> mkdir keys
resin1.2.b2> keytool -genkey -keyalg RSA -keystore keys/server.keystore
Enter keystore password: changeit
What is your first and last name?
[Unknown]: www.caucho.com
What is the name of your organizational unit?
[Unknown]: Resin Engineering
What is the name of your organization?
[Unknown]: Caucho Technology, Inc.
What is the name of your City or Locality?
[Unknown]: San Francisco
What is the name of your State or Province?
[Unknown]: California
What is the two-letter country code for this unit?
[Unknown]: US
Is <CN=www.caucho.com, OU=Resin Engineering,
O="Caucho Technology, Inc.", L=San Francisco, ST=California, C=US> correct?
[no]: yes
Enter key password for <mykey>
(RETURN if same as keystore password): changeit
Currently, the key password and the keystore password must be the same.
The Resin SSL configuration extends the http configuration with a few new
elements.
<resin xmlns="http://caucho.com/ns/resin">
<server>
<http port="8443">
<jsse-ssl>
<key-store-type>jks</key-store-type>
<key-store-file>keys/server.keystore</key-store-file>
<password>changeit</password>
</jsse-ssl>
</http>
...
</http-server>
</caucho.com>
With the above configuration, you can test SSL with https://localhost:8443.
A quick test is the following JSP.
Secure? <%= request.isSecure() %>
Nicholas Lehuen writes:
Here is a short step-by-step installation guide for SSL on Resin.
The purpose : to install SSL support on Resin
- The latest Resin 1.2 snapshot (I used the 08/04/2000 snapshot with success)
http://www.caucho.com/download/index.xtp
- JSSE 1.0.1
http://java.sun.com/products/jsse/
- Optional : a certificate authority (CA) such as Verisign, Thawte, or your own. Thawte is providing a free test certificate authority
service which enables you to check the certification process before buying your own certificate. Of course, you can also skip the CA by
providing self-signed public key certificate. This will be explained later.
https://www.thawte.com/cgi/server/test.exe
- Follow the installation instructions
http://java.sun.com/products/jsse/install.html
- Even if Resin has its own provider registration system (we'll see it on next step), I suggest that you statically register the SunJSSE
by editing the <java-home>/lib/security/java.security as explained in the installation guide. This will ease the use of keytool.
- Create a directory named 'keys' somewhere in your Resin installation. I suggest you place it in the Resin home directory.
- Copy the file <java-home>/lib/security/cacerts into the 'keys' directory
- Rename the cacerts file as you want. I'll suppose you name it 'private.keystore'.
Your private.keystore file is for the moment a copy of the cacerts keystore, which contains the CA public key certificates (very
important for client HTTPS connections). We will insert your own private key in this file, thus it'll have to be password-protected, so
that anyone stealing it will have difficulties in forging certificates on your behalf.
- Go into the 'keys' directory
- type the following command :
keytool -storepasswd -storepass changeit -new YourPasswordHere \
-keystore private.keystore
(the default password for the cacerts keystore is 'changeit')
We'll now generate your key pair, which is composed of a private (the one which MUST remain secret !) and a public key. The point here is
to use the RSA key pair generator, and NOT the default one, which is DSA. This is were the JSSE security provider is used.
type the following command :
M:\keys>keytool -genkey -keyalg RSA -alias myserverkeypair \
-storepass YourPasswordHere -keystore private.keystore
What is your first and last name?
[Unknown]: www.myserver.com
What is the name of your organizational unit?
[Unknown]: Foo Dept
What is the name of your organization?
[Unknown]: Bar
What is the name of your City or Locality?
[Unknown]: Paris
What is the name of your State or Province?
[Unknown]: France
What is the two-letter country code for this unit?
[Unknown]: FR
Is <CN=www.myserver.com, OU=Foo Dept, O=Bar, L=Paris,
ST=France, C=FR> correct?
[no]: yes
Enter key password for <myserverkeypair>
(RETURN if same as keystore password):
You MUST mention your HTTP server name as the CN of the certificate (thus the reply to 'first and last name'). Browsers would emit
warnings to your users if you didn't. Any other informations are at your choice, however the process of key pair generation and
attributes definitions is very strict for "real-life" cryptography, i.e. Verisign will double-check your identity, address and so on.
Another important point : DON'T AFFECT A PASSWORD to your key pair. It must remain the same as the keystore, at least until Resin
provides a means of configuring the key pair password.
Request a public key certificate and insert the public key certificate into your keystore.
For users to trust your server, you'll have to have your public key
certificate (PKC) signed by a Certificate Authority (CA) (Verisign,
Thawte, Certplus...). This is done by sending a certificate signature
request (CSR) to the CA, coping with all the legal stuff and
getting a signed PKC in return. This step is mandatory for production server, unless you have some means to convince your users that your
PKC is valid without a CA signature, which is possible in intranet environment for example. However, for testing purpose, you can start
by using your self-signed PKC without any CA signature. An intermediary solution is to use a test CA so that you can check that your CSR
is correctly emitted, that the Certificate Chain is correctly checked, and so on. Thawte provides a test CA at the address mentioned
above.
- Generate a CSR by typing the following command :
M:\keys>keytool -certreq -alias myserverkeypair -storepass YourPasswordHere \
-keystore private.keystore
-----BEGIN NEW CERTIFICATE REQUEST-----
MIIBqjCCARMCAQAwajELMAkGA1UEBhMCRlIxDzANBgNVBAgTBkZyYW5jZTEOMAwGA1UEBxMFUGFy
... cut ...
KDYZTklbg1NOiXTdXIhPHb3+YOgZ+HoeDTxOx/rRhA==
-----END NEW CERTIFICATE REQUEST-----
- Copy/Paste the CSR into the text box at the following address. Leave all options with their default value.
https://www.thawte.com/cgi/server/test.exe
- You'll get a certificate looking like :
-----BEGIN CERTIFICATE-----
MIICjzCCAfigAwIBAgIDBp8SMA0GCSqGSIb3DQEBBAUAMIGHMQswCQYDVQQGEwJa
... cut ...
/93Q58iI4fgQ/kc+l8ogpVwh/IJw1Ujmszd19Jf+pxyySMM=
-----END CERTIFICATE-----
- Copy/Paste this certificate into a file named 'myserver.cer' . If you have Microsoft Internet Explorer 5.0 (maybe 4.0) installed, you
can open this .cer file and see the certificate as your user will when they ask the security properties of pages served securely by your
server. A warning should be emitted, stating that you can't trust the certificate as it does not point to a trusted root CA. You can keep
going with this warning or download and trust the test root CA (available on https://www.thawte.com/servertest.crt ). Be ware though that
the final user should not and surely won't accept to trust this test root CA.
- Anyway, to be able to import your signed certificate, you'll have to import the test root CA certificate. Download it and import it
using the following command :
M:\keys>keytool -import -alias servertest -storepass YourPasswordHere \
-keystore private.keystore -file servertest.crt
Owner: CN=Thawte Test CA Root, OU=TEST, O=Thawte, ST=FOR TESTING, C=ZA
Issuer: CN=Thawte Test CA Root, OU=TEST, O=Thawte, ST=FOR TESTING, C=ZA
Serial number: 0
Valid from: Thu Aug 01 02:00:00 CEST 1996 until: Thu Dec 31 22:59:59 CET 2020
Certificate fingerprints:
MD5: 5E:E0:0E:1D:17:B7:CA:A5:7D:36:D6:02:DF:4D:26:A4
SHA1: 39:C6:9D:27:AF:DC:EB:47:D6:33:36:6A:B2:05:F1:47:A9:B4:DA:EA
Trust this certificate? [no]: yes
Certificate was added to keystore
- Import the certificate and attach it to your server key pair by typing the command :
M:\keys>keytool -import -alias myserverkeypair -storepass YourPasswordHere \
-keystore private.keystore -file myserver.cer
Certificate reply was installed in keystore
Issue the following command :
M:\keys>keytool -list -v -alias myserverkeypair -storepass YourPasswordHere \
-keystore private.keystore
Alias name: myserverkeypair
Creation date: Fri Aug 11 23:07:53 CEST 2000
Entry type: keyEntry
Certificate chain length: 2
Certificate[1]:
Owner: CN=www.myserver.com, OU=Foo Dept, O=Bar, L=Paris, ST=France, C=FR
Issuer: CN=Thawte Test CA Root, OU=TEST, O=Thawte, ST=FOR TESTING, C=ZA
Serial number: 69f12
Valid from: Fri Aug 11 23:00:07 CEST 2000 until: Mon Sep 11 23:00:07 CEST 2000
Certificate fingerprints:
MD5: 41:84:55:8C:A1:85:28:DA:B0:5A:47:D6:5B:D2:ED:41
SHA1: 61:DE:DB:E6:7C:3C:AD:90:63:9B:20:E0:FF:3B:02:3A:60:EB:B4:82
Certificate[2]:
Owner: CN=Thawte Test CA Root, OU=TEST, O=Thawte, ST=FOR TESTING, C=ZA
Issuer: CN=Thawte Test CA Root, OU=TEST, O=Thawte, ST=FOR TESTING, C=ZA
Serial number: 0
Valid from: Thu Aug 01 02:00:00 CEST 1996 until: Thu Dec 31 22:59:59 CET 2020
Certificate fingerprints:
MD5: 5E:E0:0E:1D:17:B7:CA:A5:7D:36:D6:02:DF:4D:26:A4
SHA1: 39:C6:9D:27:AF:DC:EB:47:D6:33:36:6A:B2:05:F1:47:A9:B4:DA:EA
As you can see the alias myserverkeypair points to a keyEntry type entry, its certificate chain has 2 certificate, the first being your
own certificate, signed by the Thawte Test CA Root, and the other being the Thawte Test CA Root own.
add the support for the SunJSSE security provider :
<resin xmlns="http://caucho.com/ns/resin">
<security-provider id='com.sun.net.ssl.internal.ssl.Provider'/>
<!-- declare a new HTTP server on port 443 (standard port for HTTPS),
- with SSL enabled -->
<server>
<!-- the http port -->
<http port="80"/>
<!-- the srun port, read by both JVM and plugin -->
<cluster>
<srun host='localhost' port='6802'/>
</cluster>
<http port=443>
<jsse-ssl>
<key-store-type>jks</key-store-type>
<key-store-file>file://m:/keys/private.keystore</key-store-file>
<password>YourPasswordHere</password>
</jsse-ssl>
</http>
Try connecting to your server with https instead of http !
I've been running successfully SSL on Resin with JDK 1.3 on Windows NT 4 SP6 and JDK 1.2.2 on Solaris 7.
And the fun begins when mixing HTTPS and WAP... !
Copyright (c) 1998-2009 Caucho Technology, Inc. All rights reserved. caucho® ,
resin® and
quercus®
are registered trademarks of Caucho Technology, Inc.
|
Copyright (c) 1998-2009 Caucho Technology, Inc. All rights reserved. caucho® ,
resin® and
quercus®
are registered trademarks of Caucho Technology, Inc.
|