How to use certificates to access restricted websites
Intended for:
Users who need to use certificates to access restricted websites.
Scenario/Use case:
This article provides instructions on how to use certificates to access restricted websites.
Instructions:
About website security and SSL
Websites can be set up with different types and levels of security. For example, many sites require no authentication and let anyone in, others require password authentication, and still others (the kind with which we're presently concerned) use Secure Sockets Layer (SSL) and may require user certificate authentication. By convention, URLs for web sites that require an SSL connection start with https: instead of http:.
SSL is a protocol developed by Netscape for transmitting private documents via the Internet. SSL uses public-and-private key encryption. SeaMonkey, Firefox, Internet Explorer, Chrome and other browsers support SSL.
Many websites use the SSL protocol to obtain confidential user information, such as credit card numbers. In fact, if you've ever bought merchandise over the internet, the vendor site most likely established an SSL connection with your computer, and thus had to authenticate itself (via its service certificate) to your browser. Why didn't you notice anything about certificates? Because virtually all browsers these days come with a set of commonly used CA certificates prepackaged, and when the remote site establishes the SSL connection, your browser checks behind the scenes whether the service certificate presented by that site was issued by one of the CAs it trusts. Usually there is a match, and the transaction can proceed.
The CAs that Fermilab servers typically recognize, CILogon and CERN, are available only to a small (and noncommercial) segment of the population, and are not included by default in any browsers.
What do I have to do to access SSL-protected Fermilab websites?
For sites that don't require user certificate authentication:
Depending on your browser and the remote web server configuration, you may need to import the CA certificates (and associated root CAs) into your browser to make a successful SSL connection with one of these servers.
For sites that require user certificate authentication:
In this case, you need to have the CA certificate(s) plus a personal certificate. Your valid personal certificate (e.g., a CILogon Silver CA certificate) must be loaded in your browser. When you try to access a restricted webpage your browser may prompt you to select a certificate, or may pick one by default. If it prompts you, select a valid one whose CA is trusted by the site (use the trial and error method!), and your browser will then display the page.
Some websites require you to register with them, e.g., some instances of Fermilab's DocDB. Instructions should be provided at the website.
How does SSL authentication work?
See: What is SSL and what are Certificates? for an explanation of how it works. Here is a simplified version for the case where you have to trust the remote site (e.g. before giving your credit card number):
-
You (your browser) request(s) a secure page (usually one that starts with https://).
-
The remote web server sends its service certificate which contains its public key. The electronic signature of that public key is signed by a CA for which a CA certificate exists in your browser.
-
Your browser checks that the service certificate was issued by the trusted CA. It can do so because the corresponding CA certificate in your browser contains the public key needed to check the signature. Your browser then checks that the certificate is still valid and that it matches the site contacted.
-
Your browser next uses the public key of the CA certificate to encrypt a random symmetric encryption key (called a session key), and sends it to the server (along with various other encrypted data).
-
The web server decrypts this session key using its private key and deals with the encrypted data. The remainder of the session is encrypted with the session key.
-
You and the web server can now send information back and forth (along with various other encrypted data) over the encrypted session, each of you decrypting and encrypting with the session key.
See Also: