This document provides an overview of SSL (Secure Sockets Layer) technology, including why it is used, how it works, and common troubleshooting tips. SSL addresses issues with communicating securely over the internet such as verifying identities, preventing eavesdropping, and modifying data. It uses public key cryptography where each party has a public and private key to encrypt data. The SSL handshake process negotiates encryption between client and server before transmitting encrypted data. Common SSL issues involve certificate validation errors, which can be debugged using stack traces and tools like Keytool and OpenSSL.
2. SSL
Secure Sockets Layer, or SSL (pronounced as
separate letters), is a protocol which is used to
communicate over the Internet in a secure fashion.
The following is a brief but comprehensive
introduction to SSL technology. To better understand
the need for SSL, lets first examine the difficulties of
using the Internet if no SSL encryption existed.
3. Why Use SSL?
Transferring sensitive information over a network can be risky due
to the following three issues:
You cannot always be sure that the entity with whom you are
communicating is really who you think it is.
Network data can be intercepted, so it is possible that it can be
read by an unauthorized third party, sometimes known as an
attacker.
If an attacker can intercept the data, the attacker may be able to
modify the data before sending it on to the receiver.
SSL addresses all these issues.
4. SSL Details
SSL technology relies on the concept of ‘public key
cryptography’ to accomplish its tasks. In normal
encryption, two communicating parties each share a
password or key, and this is used to both encrypt and
decrypt messages. While this is a very simple and
efficient method, it doesn’t solve the problem of
giving the password to someone you have not yet
met or trust.
In public key cryptography, each party has two keys,
a public key and a private key. Information encrypted
with a person’s public key can only be decrypted with
the private key and vice versa. Each user publicly
tells the world what his public key is but keeps his
private key for himself.
6.
Client hello - The client sends the server information including the highest version of
SSL it supports and a list of the cipher suites it supports. (TLS 1.0 is indicated as SSL
3.1.) The cipher suite information includes cryptographic algorithms and key sizes.
Server hello - The server chooses the highest version of SSL and the best cipher
suite that both the client and server support and sends this information to the client.
Certificate - The server sends the client a certificate or a certificate chain. A
certificate chain typically begins with the server's public key certificate and ends with
the certificate authority's root certificate. This message is optional, but is used
whenever server authentication is required.
Certificate request - If the server needs to authenticate the client, it sends the client
a certificate request. In Internet applications, this message is rarely sent.
Server key exchange - The server sends the client a server key exchange message
when the public key information sent in 3) above is not sufficient for key exchange.
Server hello done - The server tells the client that it is finished with its initial
negotiation messages.
Certificate - If the server requests a certificate from the client in Message 4, the
client sends its certificate chain, just as the server did in Message 3.
7.
Client key exchange - The client generates information used to create a key to use
for symmetric encryption. For RSA, the client then encrypts this key information with
the server's public key and sends it to the server.
Certificate verify - This message is sent when a client presents a certificate as
above. Its purpose is to allow the server to complete the process of authenticating the
client. When this message is used, the client sends information that it digitally signs
using a cryptographic hash function. When the server decrypts this information with
the client's public key, the server is able to authenticate the client.
Change cipher spec - The client sends a message telling the server to change to
encrypted mode.
Finished - The client tells the server that it is ready for secure data communication to
begin.
Change cipher spec - The server sends a message telling the client to change to
encrypted mode.
Finished - The server tells the client that it is ready for secure data communication to
begin. This is the end of the SSL handshake.
Encrypted data - The client and the server communicate using the symmetric
encryption algorithm and the cryptographic hash function negotiated in Messages 1
and 2, and using the secret key that the client sent to the server in Message 8.
Close Messages - At the end of the connection, each side will send a close_notify
message to inform the peer that the connection is closed.
8. To set up SSL
Weblogic
http://weblogic-wonders.com/weblogic/2010/11/11/configuring-sslon-weblogic-server-custom-identity-and-custom-trust/
Jboss
http://weblogic-wonders.com/weblogic/2010/04/07/sslconfiguration-with-jboss-server/
Websphere
http://weblogic-wonders.com/weblogic/2011/07/06/certificatemanagement-in-websphere-application-server-2/
9. Formats
.pem – (Privacy-enhanced Electronic Mail) Base64 encoded DER certificate,
enclosed between “
-----BEGIN CERTIFICATE-----"
"-----END CERTIFICATE-----"
A .pem format file supports multiple digital certificates (for example, a certificate chain
can be included). The order is important (include the files in the order of trust). The server
digital certificate should be the first digital certificate in the file. The issuer of that digital
certificate should be the next file and so on until you get to the self-signed root certificate
authority certificate.
.cer, .crt, .der – usually in binary DER form, but Base64-encoded certificates are
common too (see .pem above)
.p7b, .p7c – PKCS#7 SignedData structure without data, just certificate(s) or CRL(s)
.p12 – PKCS#12, may contain certificate(s) (public) and private keys (password
protected)
.pfx – PFX, predecessor of PKCS#12
.jks – JAVA Keystore, used to store public/private key pairs, trusted certificates
15. Common Issues
Incomplete CA Chains
Invalid keys
Certificate expiration
Required certificate not present in trust keystore
Hostname Verification Failure
16. Stack Traces
PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target
java.security.InvalidKeyException: Illegal key size
java.security.InvalidAlgorithmParameterException: the trustAnchors
parameter must be non-empty
Signature verification failed because RSA key public exponent [3] is too
small
Solutions ??
http://weblogic-wonders.com/weblogic/2010/01/28/troubleshooting-ssl-issues/