Frequently Asked Questions

New KCA Service

Q. 1.0 What is a KCA server?
Q. 1.1 What are possible common uses of KCA certificates?
Q. 1.2 Why are we changing the KCA service?
Q. 1.3 What changes are being made in the new KCA service?
Q. 1.4 What is not affected?
Q. 1.5 When is the new KCA service moving into production?
Q. 1.6 What do I need to do to prepare for the cutover?
Q. 1.7 What do the differences look like?
Q. 1.8 How can I test the new KCA service?
Q. 1.9 I am trying to test against the new KCA servers, but a kxlist output still shows my old certificate.
Q. 1.10 Where can I obtain a new DN Translation List which contains the new naming scheme?
Q. 1.11 How are you communicating these changes?
Q. 1.12 Has anyone considered DocDB, NIMI, Miser and the other web applications?
Q. 1.13 Why does my displayName for my certificate in my browser no longer report my full name?
Q. 1.14 What not use a different naming convention or other OID available in the x.509 spec?
Q. 1.15 I cannot find an answer to my question. Who should I contact?

New KCA Service

A. 1.0 What is a KCA server?

The KCA server is a service that issues an x.509 certificate after presenting a valid Kerberos ticket.

Return to top

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

KCA certificates are used to identify you for authorization to various services that cannot (or do not utilize kerebros authentication). While KCA certificates are not to be used to interactively log into a system (such as through SSH), they are appropriate for other services. Some common services include:
- Access to web pages
- DocDB
- Service Desk activities
- Mitigating TIssue events
- Various Copmuting Division resources
- Grid job submission

Return to top

A. 1.2 Why are we changing the KCA service?

We currently operate two KCA servers for redundancy. However, only one of the KCA servers had the code base to support the NetIDManager for Windows application, thus has no redundant peer. We also have various requirements to meet for continued TAGPMA accreditation. These requirements include:

Eliminate the usage of the /UID designator
Utilize a Hardware Security Module (HSM) for private key storage

The current KCA codebase cannot support these imposed requirements. The new KCA service will facilitate these and other imposed requirements in due course. In addition, the current KCA servers obtain the common name information from the FERMI Windows Active Directory entries, and is not compatible with Windows 2003 domain controllers, thus a Windows 2000 domain controller remains in operation, prohibiting enhanced offerings within the FERMI Windows Active Directory domain such as alternate operating system membership and UID/GID translations. Lastly, the platforms supporting the current KCA servers are obsolete and given the delicate nature of the current KCA codebase build process and system dependencies, OS upgrades are error prone and difficult at best. A failure would most likely result in a very long outage.

Return to top

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

The new revision of the KCA service incorporates more detailed server side logging to more easily track issued certificates to later accommodate automatic CRL generation which is transparent to the end user. The biggest changes include: - The elimination of usage of the /UID object in favor of /CN=UID:username - Changes to the creation of Robots certificates to create a DN of /DC=gov/DC=fnal/O=Fermilab/OU=Robots/CN=originator-KRB-principal-name/CN=KRB-principal-organization/CN=username/CN=UID:username

Return to top

A. 1.4 What is not affected?

Services that utilize Kerberos authentication or passwords are not affected. These include:
- Kerberos tickets
- SSH/rsh/rlogin/Telnet/FTP services
- DCACHE access via LDAP
- Email

Return to top

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

Transistion to the new KCA service is scheduled for the morning of Wednesday, May 28, 2008.

Return to top

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

If you utilize KCA certificates to validate a user to a web application without individual identity mappings (setting a .htaccess file to KCA certificates, but not explicitly mapping certificates to individual logins within your web application), there should be no noticable change. If you do perform individual identity mappings by extracting the /UID portion from the certificate, you will need to modify your code to handle the '/CN=UID:' nomenclature. Lastly, if your applications utilize an explicit DN, you will need to update your DN lists with the newly generated naming conventions.

Return to top

A. 1.7 What do the differences look like?

Here is a current KCA certificate:
issuer=/DC=gov/DC=fnal/O=Fermilab/OU=Certificate Authorities/CN=Kerberized CA
subject=/DC=gov/DC=fnal/O=Fermilab/OU=People/CN=Joe Klemencic/UID=jklemenc

And here is the new format (notice the change at the end of the subject):
issuer= /DC=gov/DC=fnal/O=Fermilab/OU=Certificate Authorities/CN=Kerberized CA
subject= /DC=gov/DC=fnal/O=Fermilab/OU=People/CN=Joe Klemencic/CN=UID:jklemenc

Return to top

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

First, you need to use the modified version of the kx509 utility which contains a feature to specify a KCA server on the command line instead of relying on DNS to resolve the KCA service. You can obtain it here (RH Linux only). After extracting, you will want to perform a kdestory to get rid of any certificates you may have already obtained. Next, perform a kinit to obtain a Kerberos ticket then execute kx509 -s 'servername' where 'servername' is the name of the KCA server you wish to test against. We have a few KCA test installations:

winserver.fnal.gov is the new production KCA server
winserver2.fnal.gov is the new production KCA server
kcaprdtest.fnal.gov is the test instance for testing bleeding edge code

After you obtain a certificate, issue the command 'kxlist' and you should see output similat to the following:
Service kx509/certificate
issuer= /DC=gov/DC=fnal/O=Fermilab/OU=Certificate Authorities/CN=Kerberized CA
subject= /DC=gov/DC=fnal/O=Fermilab/OU=People/CN='Your Name'/CN=UID:'your username'

You may now use this certificate to test your applications. Windows users can configure NetIDManager through the GUI to utilize a named KCA server.

Return to top

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

First, make sure to destroy your old certificate. In NIM, you can do so my clicking the Destroy Credentials button. If using command line tools, perform a kdestroy. Next, obtain a new Kerberos ticket. Finally, obtain a new KCA certificate. Be sure to have configured your software to point to the new KCA servers. If using get-cert.sh, there is a test kx509 binary available at http://security.fnal.gov/tools that supports the -s servername option. You will need this binary AND modify your get-cert.sh script to add '-s winserver.fnal.gov' or '-s winserver2.fnal.gov' to the $KX509PROG line (around line 104). If you choose to not use get-cert.sh, simply execute 'kx509 -s winserver.fnal.gov' using the new kx509 binary listed previously.

Return to top

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

A new DN Translation List is automatically generated at https://security.fnal.gov/pki/protected/KCA_DN_translation.txt
A DN translation list for Robot certificates is available at https://security.fnal.gov/pki/protected/KCArobots_DN_translation.txt

Return to top

A. 1.11 How are you communicating these changes?

For most of the FNAL population, these changes will go unnoticed, so a general broadcast announcement was considered, but not feasible. We have been trying to get the 'right people', especially large stakeholders, to help plan for the changes. We will announce the changes in the upcoming CD Tracks newsletter.

Return to top

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

Yes. The Core Services developers have been engaged during the planning process and many of their services are now accepting both old and new KCA certificates.

Return to top

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

Many applications will print only the last /CN found within a DN. In the case of the KCA (at this time), the last object in the DN is /CN=UID:username. Thus, your browser finds the last /CN in the string and displays everything after the equal sign.

Return to top

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

his is a long discussion. We were using /UID=username, but some OpenSSL versions reported the oid-to-name mapping inconsistently. Since this was casuing problems, TAGPMA encouraged us to change to a different scheme. We looked at other OID's available along with appending additional /CN objects, and decided on /pseudonym=username as to to interfere with the original DN. However, due to inconsistencies in the BouncyCastle software used by much grid middleware, this was abandoned. We then had a shoot out of /CN=UID= and /CN=UID: and /CN=UID: had the least impact in the grid (BouncyCastle still had inconsistencies with /CN=UID=). There are countless different ways to handle this, including inventing our own OID, but it was decided to stick with something that supports the lowest common denominator while providing an easy to parse object to extract the Fermi username.

Return to top

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

If you are having a general problem obtaining or using a KCA certificate, please open a help desk ticket by calling the Help Desk at x2345 or through their web interface at http://helpdesk.fnal.gov. If you have concerns or questions about the transition to the new KCA service, you may email the Computer Security Team at cst @ fnal.gov.

Return to top

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