Fermilab Computing Division

How to Get your Website to run SSL and
(optionally) User Certificate Authentication

sidemenu

Restricted Access

Web server administrators and web authors

This page is intended primarily for web authors. Information for server administrators is available separately for IIS and Apache.

Why do you want to implement SSL?

There are several ways in which SSL can make your site more secure.

  • If you have sensitive data on your site, or the site is intended for a limited audience, you may want to implement user certificate authorization, which requires SSL.
  • You may want to use password authentication, but you don't want the passwords going over the network in the clear; use SSL to encrypt them. Similarly, use SSL if you want to upload/download any sensitive data .
  • You can use SSL to hide the identity of individuals looking at particular pages.

See also Restricting Access to Web Pages.

Find out about the web server that hosts your site

Many web authors are not server administrators, are not familiar with the configuration of the hosting server and in fact do not even know if it runs Apache or IIS. The web author and the server administrator need to cooperate in order to implement SSL (and user certificate authentication, if desired).

To find out if the server is configured for SSL, go to the URL in question, and replace the http with https. If that works, then SSL is set up. If not, your server admin will either need to set it up or ask you to move your site to a different server.

To contact the server admin, create a helpdesk ticket stating that you wish to have SSL (and optionally client authentication via certificates) set up on your site. Here are some guidelines for the ticket problem description:

  • Provide your site address (URL and path)
  • Is the server Apache or IIS?
  • If the server is not SSL-enabled, can the server admin set it up? (Note that this is more likely to get a positive response if you're asking about a "fnal.gov" server as opposed to a ".org" server, for reasons of cost and convenience; ".org" sites require purchasing a certificate from a commercial CA.)
  • If so, which CA(s) are trusted, KCA, DOEGrids, or some other?
  • List the CA(s) you require, if already determined.
  • (If you want to implement user certificate authorization) Has the server been configured for inbound access by individuals via client certificates?
  • If not, request that it be configured for this, if needed.

Determine your web site's audience

If you want user certificate authentication enabled, figure out who should have access to your site, and how to distinguish this group from all other users. Some examples of groupings:

  • Fermi people (i.e., FNAL.GOV Kerberos domain users eligible for KCA certificates)
  • DOE-affiliated people (i.e., anyone who has DOEGrids certificate)
  • Specific individuals with certificates from a known set of CAs
  • Anyone with a certificate issued by a particular CA and connecting from a particular domain (e.g., fnal.gov)
  • Some combination of the above

Identify authorized users by Distinguished Name (DN)

Using CA's DN

If you select authorized individuals based on the CA that issued their certificates (e.g., anyone with DOEGrids cert), you'll need to know the Distinguished Name (DN) of the CA. This is available on any certificate issued by the CA.

For DOEGrids the DN is:

DC = org/DC = DOEGrids/OU = Certificate Authorities/CN = DOEGrids CA 1

For KCA, the DN is:

/DC=gov/DC=fnal/O=Fermilab/OU=Certificate Authorities/CN=Kerberized CA

Using Individual's DN

If you select authorized individuals based on their personal certificates, you'll need to know their DNs (the subject DN of their certificate), and of course the issuing CAs. The subject DN is of the form (shown for DOEGrids): /DC = org/DC = doegrids/OU = People/CN = Issuee Name 123456

The DOEGrids site has a search function where you can find this information.

For the KCA there is a (protected) translation list from Kerberos principal to KCA DN (KCA translation list for cron/kcron jobs ).

If you can't access the translation list, for KCA using Linux, you can do an LDAP search as follows (sn stands for SurName; use your kerberos principal):

ldapsearch -x -u -v -h ldap.fnal.gov -b o=fnal '(sn=myname)'

The parts you need are:

  • the "uid=xxx" part of the "dn:" (Distinguished Name) field,
  • the "cn:" (Common Name) field

The above ldapsearch command above gives:

       dn: uid=myname,o=fnal
       ...
       cn: Joe Myname
       ...

which makes the KCA cert subject DN:

/DC=gov/DC=fnal/O=Fermilab/OU=People/CN=Joe Myname/UID=mengel
                                      ---cn---     --uid--

For KCA using Windows (in Fermi domain) , go to the command prompt, cd to C:\WINDOWS\system32 (if not in path) and enter (didn't work for me, command unrecognized):

     dsquery user -name *Mengel | dsget user -display -dn

This gives output like:

     dn                             display

     CN=mengel,OU=General...        Marc W. Mengel x8256 09670N

        --uid-                      ------cn------

   And you get the text as above.

Add the authorized users

If your server is IIS, give this information to server admin, have him/her set it up. Best to request this using the same helpdesk ticket that you created earlier to get the initial information about the server.

If your server is Apache, you can edit the .htaccess file. You'll need to add an " sslrequire" command. This is described in detail towards the end of the page Setting up an SSL server with the Fermilab apache product.

Test your site

Details depend on your implementation.

For assistance contact helpdesk@fnal.gov.
Information compiled and maintained by Computer Security Team ; last modified by TR on July 13, 2006.
(Address comments about page to the Computer Security Team.)