このコンテンツは選択した言語では利用できません。
6.4. How to Use X.509 Certificates
| Revision History | |
|---|---|
| 8/29/12 | |
| changed supported status of mutual auth to address MB-1216 | |
Overview
Before you can understand how to deploy X.509 certificates in a real system, you need to know about the different authentication scenarios supported by the SSL/TLS protocol. The way you deploy the certificates depends on what kind of authentication scenario you decide to adopt for your application.
Target-only authentication
In the target-only authentication scenario, as shown in Figure 6.1, “Target-Only Authentication Scenario”, the target (in this case, the broker) presents its own certificate to the client during the SSL/TLS handshake, so that the client can verify the target's identity. In this scenario, therefore, the target is authentic to the client, but the client is not authentic to the target.
Figure 6.1. Target-Only Authentication Scenario
The broker is configured to have its own certificate and private key, which are both stored in the file,
broker.ks. The client is configured to have a trust store, client.ts, that contains the certificate that originally signed the broker certificate. Normally, the trusted certificate is a Certificate Authority (CA) certificate.
Mutual authentication
In the mutual authentication scenario, as shown in Figure 6.2, “Mutual Authentication Scenario”, the target presents its own certificate to the client and the client presents its own certificate to the target during the SSL/TLS handshake, so that both the client and the target can verify each other's identity. In this scenario, therefore, the target is authentic to the client and the client is authentic to the target.
Figure 6.2. Mutual Authentication Scenario
Because authentication is mutual in this scenario, both the client and the target must be equipped with a full set of certificates. The client is configured to have its own certificate and private key in the file,
client.ks, and a trust store, client.ts, which contains the certificate that signed the target certificate. The target is configured to have its own certificate and private key in the file, broker.ks, and a trust store, broker.ts, which contains the certificate that signed the client certificate.
Selecting the authentication scenario
Various combinations of target and client authentication are supported by the SSL/TLS protocols. In general, SSL/TLS authentication scenarios are controlled by selecting a specific cipher suite (or cipher suites) and by setting the
WantClientAuth or NeedClientAuth flags in the SSL/TLS protocol layer. The following list describes all of the possible authentication scenarios:
- Target-only authentication—this is the most important authentication scenario. If you want to authenticate the client as well, the most common approach is to let the client log on using username/password credentials, which can be sent securely through the encrypted channel established by the SSL/TLS session.
- Target authentication and optional client authentication—if you want to authenticate the client using an X.509 certificate, simply configure the client to have its own certificate. By default, the target will authenticate the client's certificate, if it receives one.
- Target authentication and required client authentication—if want to enforce client authentication using an X.509 certificate, you can set the
NeedClientAuthflag on the SSL/TLS protocol layer. When this flag is set, the target would raise an error if the client fails to send a certificate during the SSL/TLS handshake. - No authentication—this scenario is potentially dangerous from a security perspective, because it is susceptible to a man-in-the-middle attack. It is therefore recommended that you always avoid using this (non-)authentication scenario.NoteIt is theoretically possible to get this scenario, if you select one of the anonymous Diffie-Hellman cipher suites for the SSL/TLS session. In practice, however, you normally do not need to worry about these cipher suites, because they have a low priority amongst the cipher suites supported by the
SunJSSEsecurity provider. Other, more secure cipher suites normally take precedence.
Custom certificates
For a real deployment of a secure SSL/TLS application, you must first create a collection of custom X.509 certificates and private keys. For detailed instructions on how to go about creating and managing your X.509 certificates, see Appendix A, Managing Certificates.
