Análisis individual de los datos

1 Create a server certificate—If you use keytool to generate a self-signed certificate on the server machine, this certificate is automatically placed within a keystore. Here’s an example of the command that you’d run:

keytool -genkey -alias serverCertificate -keyalg RSA -validity 1500

➥ -keystore server.keystore

2 Create a client certificate—If you use keytool to generate a self-signed certificate on the client machine, this certificate is automatically placed within a keystore. Here’s an example of the command that you run:

keytool -genkey -alias clientCertificate -keyalg RSA -validity 1500

➥ -keystore client.keystore

3 Export the client certificate from the keystore (on the client)—You export the certificate so that you can import it into a truststore used by the server. In the following

example, you export the certificate to a file called client.cer:

keytool -export -alias clientCertificate -keystore client.keystore

➥ -file client.cer

4 Import certificate into browser—Convert the certificate to a format compatible with the client’s browser (see next section) and import the certificate into the cli- ent’s browser.

5 Create server truststore—Copy the client certificate (client.cer in this case) to the server and import the client certificate into a truststore (on the server).

keytool -import -alias clientCertificate -keystore server.truststore

➥ -file client.cer

6 Configure the HTTPS connector—Point to the server truststore and server keystore in the HTTPS connector definition in JBoss Web Server’s server.xml file and set the

clientAuth attribute to true.

<Connector protocol="HTTP/1.1" SSLEnabled="true" port="8443" address="${jboss.bind.address}" scheme="https" secure="true" clientAuth="true" keystoreFile="${jboss.server.home.dir}/conf/server.keystore" keystorePass="server-keystore-pass" truststoreFile="${jboss.server.home.dir}/conf/server.truststore" truststorePass="server-truststore-pass" sslProtocol="TLS" />

Note that setting clientAuth to true causes JBoss Web Server to authenticate the cli-

ent’s certificate at the protocol level. If the users access a secured page, they still need to provide a password to authenticate at the application level. We mentioned earlier that you might need to convert your certificate to a different format in order for your browser to support it. Let’s talk about that.

6.4.4 Creating browser certificates

If you want the server to authenticate a client browser, the browser needs a certificate. Whether you create a self-signed certificate or get one from a certificate authority, you probably have to convert the certificate into a different format to import it into your

browser. Most major web browsers support the PKCS12 certificate format. Although it’s not difficult to do, there are quite a few steps, precluding us from covering the specif-

ics within the scope of this book. But we do have a reference to the JBoss Wiki at the

end of this chapter that shows you how to convert X509 certificates created by keytool

to PKCS12 certificates using a tool called openssl. We also show you how to convert the certificate format in the source code that ships with the book.

So far, we’ve been using certificates to authenticate at the protocol level. If you want to use the client’s certificate as the credential to authenticate users on the server, you can enable client-certificate authentication, which we’ll talk about next.

6.5

Enabling client-certificate authentication

In chapter 4, we introduced you to client-certificate authentication, a mechanism by which you can use a client’s public key certificate as an authentication credential. When communicating with a web server, this certificate must be installed in the cli- ent’s browser. Web-based client-certificate authentication only works if a secured

HTTP connector handles the client’s request. Information in the certificate is passed

to the security domain to authenticate and authorize the user at the applica- tion level.

NOTE Keep in mind that client-certificate authentication gives you greater

source integrity but doesn’t necessarily do a good job of asserting a human user’s identity. For example, if you have a certificate on your machine and use it to authenticate against a server using client-certificate authentication, somebody else could sit behind the keyboard, and the server wouldn’t know, care, or ask him to prove who he is. One way to

verify a client certificate and challenge the user for a password is to set

clientAuth to true in the secure HTTP connector as we discussed in sec-

tion 6.4.3; then use FORM, BASIC, or DIGEST authentication to secure vari-

ous URLs. The secure HTTP connector takes care of the source

authentication at the protocol level by using mutual authentication while the application-level authentication challenges the user for a password. You have the best of both worlds. The only caveat is that all connections to the secure server require client certificates, whether or not they’re going to a secured resource.

To enable client-certificate authentication, you must follow these steps:

■ _{Enable protocol-level mutual authentication as described in section 6.4.}

■ _{Set the authentication method in your web application to} CLIENT-CERT.

■ _{Define a security-domain MBean that points to the keystore containing the}

server certificate.

■ Define the security domain in the login-config.xml file.

■ Point to the security domain in the applications jboss-web.xml file.

155