Java Reference
In-Depth Information
Certificate fingerprints:
MD5: 52:9F:49:68:ED:78:6F:39:87:F3:98:B3:6A:6B:0F:90
SHA1:
EE:2E:2A:A6:9E:03:9A:3A:1C:17:4A:28:5E:97:20:78:3F:
SHA256:
80:05:EC:7E:50:50:5D:AA:A3:53:F1:11:9B:19:EB:0D:20:67:C1:12:
AF:42:EC:CD:66:8C:BD:99:AD:D9:76:95
Signature algorithm name: SHA256withRSA
Version: 3
...
Trust this certificate? [no]:
5. Type
yes
, then press the Enter or Return key.
The following information appears:
Certificate was added to keystore
[Storing cacerts.jks]
Adding Users to the Certificate Realm
In the
certificate
realm, user identity is set up in the GlassFish Server security con-
text and populated with user data obtained from cryptographically verified client certific-
ates. For step-by-step instructions for creating this type of certificate, see “
Working with
Digital Certificates
”
on page
311
.
Using a Different Server Certificate with the GlassFish Server
Follow the steps in “
Creating a Server Certificate
” on page
312
to create your own server
certificate, have it signed by a CA, and import the certificate into
keystore.jks
.
Make sure that when you create the certificate, you follow these rules:
• When you create the server certificate,
keytool
prompts you to enter your first
and last name. In response to this prompt, you must enter the name of your server.
For testing purposes, this can be
localhost
.
• The server/host specified in the keystore must match the host identified in the
javaee.server.name
property specified in the
tut-install
/examples/bp-
project/build.properties
file for running the example applications.
• Your key/certificate password in
keystore.jks
should match the password of
your keystore,
keystore.jks
. This is a bug. If there is a mismatch, the Java
SDK cannot read the certificate and you get a “tampered” message.
