Authentication
Authentication verifies identity.
The server uses authentication in two ways:
- Digital signature.
A digital signature represents a unique mathematically computed signature that ensures accountability. Think of a digital signature as similar to a credit card, on which our photo displays. To verify the identity of the person that is sending we a message, look at the digital certificate of the sender.
- Digital certificate.
A digital certificate, or digital ID, is similar to having a credit card with a picture of the bank president with his arm around you. A merchant trusts we more because not only do we look like the picture on the credit card, the bank president trusts you, too.
We base our trust of the sender authenticity on whether we trust the third party, a person, or agency that certified the sender. The third party issuing digital certificates is called a certificate authority (CA) or certificate signer.
A digital certificate contains:
- The public key of the person getting certified
- The name and address of the person or organization getting certified, also known as the distinguished name
- The digital signature of the CA
- The issue date of the certificate
- The expiration date of the certificate
We enter our distinguished name as part of a certificate request. The digitally signed certificate includes our distinguished name and the distinguished name of the CA.
We can request one of the following certificates:
- A server certificate to do commercial business on the Internet from VeriSign or some other CA. For a list of supported CAs, see Buying a certificate from an external CA provider.
- A server certificate that we create for our own private Web network.
CAs broadcast their public key and distinguished name bundled together so that people add them to their Web servers and browsers, as a trusted CA certificate. When we designate the public key and certificate from a CA to become a trusted CA certificate, our server trusts anyone who has a certificate from that CA. We can have many trusted CAs as part of our server. The HTTP Server includes several default trusted CA certificates.
You can add, or remove trusted CAs, using the IBM Key Management utility that is included with our server.
You can add, or remove trusted CAs, using the native z/OS key management (gskkyman).
To communicate securely, the receiver in a transmission must trust the CA who issued the sender certificate. This situation remains true whether the receiver is a Web server or a browser. When a sender signs a message, the receiver must have the corresponding CA-signed certificate and public key designated as a trusted CA certificate.
Related concepts
Encryption