apache ssl

1. http://httpd.apache.org/docs/2.4/ssl/ssl_intro.html

http client

http://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html#d5e436

http://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#KMandTMdef

http://www.ibm.com/developerworks/cn/opensource/os-httpclient/

http://blog.sina.com.cn/s/blog_6941438f0101eo3d.html

http://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#KeyClasses

http://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#CustomizingStores

http://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#Debug

http://hi.baidu.com/cheng7610/item/c3f7a20f43f19ef2a110342b

http://blog.csdn.net/songylwq/article/details/7028010

jersey：

https://gist.github.com/outbounder

Truststore and keystore 

http://zctya.blog.163.com/blog/static/120917820125139712222/

Truststore and keystore: What are they and why do I care?

The SSL protocol is based on public-key cryptography where encryption keys come in pairs that are mathematically related, but one cannot be deduced from knowing the other. The pair consists of the private key and the public key (private, public). The private key remains under the protection of the entity to which it belongs. Note that the owner really owns the pair, but the public key, as its name suggests, can be publicly known, or at least is freely disseminated to the entities that communicate with the owner of the public/private key pair. The security services that public key cryptography enable are based on the fact that a message encrypted using the public key can only be decrypted by the corresponding private key, and vice versa. Thus, if one encrypts a message using the public key of an entity, then it is guaranteed that only the entity can decrypt the message. An immediate question that comes to mind is how to be assured that the public key being used is indeed bound to a legitimate entity and not to someone else. That is where Public Key Infrastructures (PKI) comes into play (see Resources).

Figure 1. The relationship between client and server truststore/keystore

Public Keys are distributed in containers called public key certificates (PKC). These are data constructs digitally signed by some signer (typically a Certificate Authority, but public keys can be self-signed). A digital signature stamps a proof of origin authenticity. One point to remember is that trust in computer security must be computationally verifiable. In order to verify that a public key certificate is legitimate, I need to verify the signature of the signer that issued it. This process is, in turn, based on the public key of the signer.

This is where the truststore comes into play. When using JSSE for SSL communication, one needs to maintain the set of trusted signer certificates in a local store, hence the name truststore. The truststore on the client side, for example, is used by the JSSE runtime in order to verify that a client attempting to connect to a server is indeed interacting with a server with a legitimate certificate (one that is issued by a trusted signer). Therefore, the signer of the server certificate must have a PKC stored in the truststore of the client. Figure 1 illustrates the relationship between client and server truststore/keystore.

By the same token, the server must have its private key locally protected and make it accessible to the JSSE runtime. That's where the keystore comes into play. A keystore has the same format as a truststore, it just contains different keys. In fact, the generic term "keystore" is typically used to mean "truststore or keystore."

In summary, truststores contain certificates for the signers that are trusted in the environment where the truststore is used. A keystore, on the other hand, maintains the private key of an entity, as well as its corresponding PKC. For example, when a server authenticates itself to the client, it needs to retrieve its private key from its keystore in order to engage in an SSL handshake with the client. So, one should really care about what signers to trust; that is, the content of the truststore being used. The IBM-provided default truststore includes several well known and widely trusted Certificate Authorites (CA). One good practice here is to periodically browse through your truststore and make your own judgment about the trustworthiness of its content -- and possibly remove some CAs.

Now that we know what a truststore is and what a keystore is, let's look at how they are defined in the WebSphere Application Server environment using the IBM JSSE.

1. JSSE reference guide for java2

http://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html

JSSE provides both an application programming interface (API)framework and an implementation of that API.The JSSE API supplements the "core" network and cryptographic servicesdefined in the Java 2 SDK, v1.4 and laterjava.security and java.net packages by providing extended

networking socket classes, trustmanagers, key managers, SSLContexts, and a socket factory framework for encapsulating socket creation behavior. (It also provides alimited public key certificate API that is compatible with Java Development Kit(JDK) 1.1-based platforms. However, please note that this limitedjavax.security.certcertificate API is provided only for backward compatibility with JSSE1.0.x and should not be used. Instead, use the standardjava.security.certcertificate API.) Because the socket APIs were based on ablocking I/O model, in J2SE 5, a non-blockingSSLEngine APIwas introduced to allow implementations to choose their own I/O methods.

JSSE Standard API

1. The JSSE(java Secure Socket Extension) standard API, available in the javax.net,javax.net.ssl andjavax.security.certpackages, covers:

• Secure (SSL) sockets and server sockets.
• A non-blocking engine for producing and consuming streams of SSL/TLS data (SSLEngine).
• Factories for creating sockets, server sockets,SSL sockets, and SSL server sockets.Using socket factories you can encapsulate socket creationand configuration behavior.
• A class representing a secure socket context that acts as afactory for secure socket factories and engines.
• Key and trust manager interfaces(including X.509-specific key and trust managers), andfactories that can be used for creating them.
• A class for secure HTTP URL connections (HTTPS).
• A public key certificate API compatible withJDK 1.1-based platforms

2. All new applications should use java.security.cert.The javax.security.cert package exists only for backwardcompatibility with previous JSSE releases, and should no longer beused.

3. The implementation now uses javax.net.ssl.SSLPermissions

4.

New methods setSessionTimeout and getSessionTimeoutwere added toSSLSessionContext. They allow the developerto control when sessions timeout and become invalid. New methodssetSessionCacheSizeandgetSessionCacheSizewere also added to control how many sessions should be cached for reuseby future connections.

New methods were added to HttpsURLConnection, SSLSession, andHandshakeCompletedEvent(all injavax.net.ssl)that allow you to get generic Java 2java.security.cert.Certificatecertificates inaddition to thejavax.security.cert.X509Certificatecertificates returned by previously-existing methods. The new methodsare

SSLSession.getPeerCertificatesHandshakeCompletedEvent.getPeerCertificatesHttpsURLConnection.getServerCertificates

A getLocalCertificates method was added to SSLSession,HandshakeCompletedEvent, andHttpsURLConnection.This method returns the certificate(s) that were sent to the peerduring handshaking. This provides a way to determine whatcertificate chain was actually used to authenticate the localside of a given SSL session.

A new interface ManagerFactoryParameters wasadded as a base interface that providers can extendif they needKeyManagerFactory and/orTrustManagerFactoryinitialization parameters other than the ones that can be passed to theKeyStore-basedinit methods of those classes. TheKeyManagerFactoryandTrustManagerFactory classes each have a newinitmethod that takes aManagerFactoryParametersargument. Users of a particular provider are expected to pass animplementation of the appropriateManagerFactoryParametersas defined by the provider.

5.Related Documentation 

JSSE API documentation:

• javax.net package
• javax.net.ssl package
• javax.security.cert package

Secure Sockets Layer (SSL) Protocol Overview

Secure Sockets Layer (SSL) is the most widely used protocolfor implementing cryptography on the Web. SSL uses a combinationof cryptographic processes to provide secure communicationover a network. This section provides anintroduction to SSL and the cryptographic processes it uses.

SSL provides a secure enhancement to the standard TCP/IPsockets protocol used for Internet communications. Asshown in the "TCP/IP Protocol Stack With SSL" figure below, thesecure sockets layer is added between the transport layer andthe application layer in the standard TCP/IP protocol stack.The application most commonly used with SSL is HypertextTransfer Protocol (HTTP), the protocol for Internet Webpages. Other applications, such as Net News Transfer Protocol(NNTP), Telnet, Lightweight Directory Access Protocol(LDAP), Interactive Message Access Protocol (IMAP), andFile Transfer Protocol (FTP), can be used with SSL as well.

Note: There is currently no standard for secure FTP.

TCP/IP Protocol Stack With SSL

TCP/IP Layer

Protocol

Application Layer

    HTTP, NNTP, Telnet, FTP, etc.

Secure Sockets Layer

    SSL

Transport Layer

    TCP

Internet Layer

    IP