apache ssl
2013-10-14 22:37
459 查看
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
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.
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 later
and
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 limited
the socket APIs were based on ablocking I/O model, in J2SE 5, a non-blocking
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
3. The implementation now uses
4.
New methods
also added to control how many sessions should be cached for reuseby future connections.
New methods were added to
to the
A
way to determine whatcertificate chain was actually used to authenticate the localside of a given SSL session.
A new interface
to theKeyStore-based
provider are expected to pass animplementation of the appropriate
javax.net packagejavax.net.ssl packagejavax.security.cert package
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.
Protocol
Application Layer
HTTP, NNTP, Telnet, FTP, etc.
Secure Sockets Layer
SSL
Transport Layer
TCP
Internet Layer
IP
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/outbounderTruststore 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.htmlJSSE 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 later
java.security
and
java.netpackages 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 limited
javax.security.certcertificate API is provided only for backward compatibility with JSSE1.0.x and should not be used. Instead, use the standard
java.security.certcertificate API.) Because
the socket APIs were based on ablocking I/O model, in J2SE 5, a non-blocking
SSLEngineAPIwas 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 thejavax.net,
javax.net.ssland
javax.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.certpackage 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
setSessionTimeoutand
getSessionTimeoutwere added to
SSLSessionContext. They allow the developerto control when sessions timeout and become invalid. New methods
setSessionCacheSizeand
getSessionCacheSizewere
also added to control how many sessions should be cached for reuseby future connections.
New methods were added to
HttpsURLConnection,
SSLSession, and
HandshakeCompletedEvent(all in
javax.net.ssl)that allow you to get generic Java 2
java.security.cert.Certificatecertificates inaddition
to the
javax.security.cert.X509Certificatecertificates returned by previously-existing methods. The new methodsare
SSLSession.getPeerCertificates HandshakeCompletedEvent.getPeerCertificates HttpsURLConnection.getServerCertificates
A
getLocalCertificatesmethod was added to
SSLSession,
HandshakeCompletedEvent, and
HttpsURLConnection.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
ManagerFactoryParameterswasadded as a base interface that providers can extendif they need
KeyManagerFactoryand/or
TrustManagerFactoryinitialization parameters other than the ones that can be passed
to theKeyStore-based
initmethods of those classes. The
KeyManagerFactoryand
TrustManagerFactoryclasses each have a new
initmethod that takes a
ManagerFactoryParametersargument. Users of a particular
provider are expected to pass animplementation of the appropriate
ManagerFactoryParametersas defined by the provider.
5.Related Documentation
JSSE API documentation:javax.net packagejavax.net.ssl packagejavax.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 cryptographicprocesses 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 LayerProtocol
Application Layer
HTTP, NNTP, Telnet, FTP, etc.
Secure Sockets Layer
SSL
Transport Layer
TCP
Internet Layer
IP
相关文章推荐
- windows下安装apache并配置ssl全过程
- apache的SSL端口被占用的解决方案
- 新StartSSL免费SSL证书申请使用:Apache和Ngnix安装配置SSL证书
- Apache 使用ssl模块配置HTTPS
- Apache SSL配置
- Apache配置HTTPS协议搭载SSl配置全过程
- 为apache添加SSL支持
- openssl自建证书SSL+apache
- 在Ubuntu 13.10 下安装支持SSL的Apache
- linux+svn+apache+ssl+ftp配置安全易于管理的svn服务器
- Apache-SSL/Apache-ModSSL
- Ubuntu下Apache SSL的配置方法
- SSL证书安装指南 - Apache-SSL / Apache ModSSL
- 如何让apache 支持ssl
- RHEL5上组建Apache+SSL+PHP+PostgreSQL环境详解(一)
- Windows平台Apache 2.2.8+SSL安装
- Linux 下 Trac SVN apache SSL 配置安装以及整合
- How To Create a SSL Certificate on Apache for Debian 8 htttps
- apache ssl 证书申请
- apache 在 加载openssl 模块时出现 “/usr/local/ssl/lib/libssl.a: could not read symbols: Bad value”错误解决方案