New KCA Service

New KCA Service

A. 1.0    What is a KCA server?

A. 1.1    What are possible common uses of KCA certificates?

A. 1.2    Why are we changing the KCA service?

• Utilize a Hardware Security Module (HSM) for private key storage
• Only issue certificates when clients use at least 1024 bit encryption

A. 1.3    What changes are being made in the new KCA service?

A. 1.4    What is not affected?

A. 1.5    When is the new KCA service moving into production?

A. 1.6    What do I need to do to prepare for the cutover?

• If you use windows platforms to obtain KCA certificates to authenticate yourself to web or other services, you do not have to do anything. NetID manager already uses 1024 bit encryption, and will automatically go to the new server when it goes into production. You can test the new server using the suggestions given below. If you are getting your kca certificates through get-cert or some other obsolete method, please switch to NetID manager, your osbolete clients are not supported and if by some miracle they are still working now they will no longer work with the new KCA server.
• If you use windows platforms to obtain KCA certificates to authenticate yourself to web or other services, you will probably need to download a new kx509 client that supports 1024 bit encryption. The clients can be obtained here
If you run web or other services that expect users to present kca certificates for authentication, you will need to install the new kca root certificate in your application server. The root cert can be obtained here. Please update your service as soon as possible (you can include the certs from both the old kca server and the new one at the same time) so that users can test your service with certs they get from the new server before it goes into production.

A. 1.7    What do the differences look like?

A. 1.8    How can I test the new KCA service?

• winserver.fnal.gov is the old production KCA server
• winserver2.fnal.gov is the redundant production KCA server
• fermi-kcatest01.fnal.gov is the test KCA

A. 1.9    I am trying to test against the new KCA servers, but a kxlist output still shows my old certificate.

A. 1.10    Where can I obtain a new DN Translation List which contains the new naming scheme?

A. 1.11    How are you communicating these changes?

A. 1.12    Has anyone considered DocDB, NIMI, Miser and the other web applications?

A. 1.13    Why does my displayName for my certificate in my browser no longer report my full name?

A. 1.14    What not use a different naming convention or other OID available in the x.509 spec?

A. 1.15    I cannot find an answer to my question. Who should I contact?

A. 1.16    How can I reconfigure my web server to use the new KCA service?

(Submitted by the CD/LSC/CSI/WCS Web Team)
Instructions for adding new Fermi CA to your Apache web server
---------------------------------------------------------------

1) Get the new CA file from the security web site in PEM format.
   http://security.fnal.gov/pki/final-kcaprod.txt

2) Add it into the trustedcas directory for you web server.
   If you are not sure where this is, you can check your
   Apache web configuration for a line that looks like:

   SSLCACertificatePath /path/to/your/trustedcas

   Keep the old CA file (e1fce4e9.0) in the trustedcas dir
   so that current browser certs continue to work. It is fine
   to have both CA files. Keep the old CA file until at least
   7 days after the switchover since people may be using browser
   certs issued before the switchover that haven't expired yet.

3) Check whether you already have a file named 99f9f5a3.0
   in that trustedcas directory or not. If so, move it aside.

4) Rename the final-kcaprod.txt from step #1 to: 99f9f5a3.0

5) Check that the 99f9f5a3.0 file permissions are such that
   the account your web server is running under can read it.

6) If you do not already have a file named 99f9f5a3.0
   in your trustedcas directory, you do NOT need to
   restart your web server for the change to take effect.

   If you did already have a diffent file named 99f9f5a3.0
   in your trustedcas directory, you will need to restart
   your web server for the change to take effect.

7) Try it out. Follow security's instruction's to get a
   new client cert on your web browser and then visit
   KCA protected areas of your web site.
   http://security.fnal.gov/pki/new2kcafaq.html#1_8

   [I tested the new CA on the test central web server with
   access restriction by KCA name, Fermilab  organization,
   and issuer match. I also tested that old browser certs
   still worked after new CA installed. Tests worked fine.]

8) The issuer DN format in the client/browser cert has changed.
   Instead of ending in "CN=Kerberized CA", they now end in
   "CN=Kerberized CA HSM" - with an extra "HSM" on the end.

   Check your web content for .htaccess files with commands
   which rely on matching the old issuer DN format (without
   the "HSM" at the end). If you find that, then add an OR
   so that the issuer's DN can be either with or without HSM
   (so it will work both now and after the switchover).

   Example: If your .htaccess file has this issuer DN reference:
   (all on one line)

SSLRequire  (%{SSL_CLIENT_I_DN} eq "/DC=gov/DC=fnal/O=Fermilab/OU=Certificate Authorities/CN=Kerberized CA")

   You should change it to check for either old style or new:
   (all on one line)

SSLRequire  (%{SSL_CLIENT_I_DN} eq "/DC=gov/DC=fnal/O=Fermilab/OU=Certificate Authorities/CN=Kerberized CA") or (%{SSL_CLIENT_I_DN} eq "/DC=gov/DC=fnal/O=Fermilab/OU=Certificate Authorities/CN=Kerberized CA HSM")

    You should be able to find these files with a find command
    such as (Linux Find with Linux switches used here):

    # find the paths of all .htaccess files with commands
    # that have SSL_CLIENT_I_DN in them. Then "more" the files.
    cd root_of_your_web_content
    find . -noleaf -name .htaccess -follow -exec grep -li "SSL_CLIENT_I_DN" {} \; >htaccesskca.all
    more `cat htaccesskca.all`

    You will only need to change the entries if they are doing
    a match that includes the "CN=Kerberized CA" field. You
    can remove the non-"HSM" entry after at least 7 days after
    the switchover (to allow browser certs issued by the old
    service to work until they expire after 7 days).

9) Check your web CGIs or applications. If they do any
   authentication based on the issuer DN, that code may also
   need to be changed to match with or without the "HSM".

If you have questions, please submit a service desk ticket assigned to CD/LSC/CSI/WCS Web Team.

***** Additional notes from Web Team *****
If after following the above instructions, you can no longer access your web site via HTTPS, be sure that the trustedcas dir
(and dirs above it) must be readable by the web server account, and not just root.
When a directory is used for trustedcas (as opposed to a file) apache looks at the directory beyond just startup
(otherwise putting the new CA in without a server restart wouldn't work), so the web server account needs to be able to read it too.

For assistance contact helpdesk@fnal.gov.
Information compiled and maintained by Computer Security Team ; last modified by IG on Apr 1, 2009.
(Address comments about page to the Computer Security Team.)