Obtaining host certificates for Grid servers

Our host certificates are issued by the SWITCH CA (using the QuoVadis service). Go here for the web interface for the ordering via certificate request files.

Email request should be sent from CERN account. The following list of CERN Authorities should be recorded to enable digital signing with user certificate:

• CERN Grid Certification Authority;
• CERN Certification Authority;
• CERN Root Certification Authority 2;

The keys and certificates are stored in a directory structure on the admin node

• /root/clusteradmin/etc/hostkeys: contains helper scripts
• /root/clusteradmin/etc/hostkeys/egieu/: contains key files, csr requests
• /root/clusteradmin/etc/hostkeys/switch-QuoVadis/certs-2011/: contains certificates valid for a certain period

In /root/clusteradmin/etc/hostkeys on t3admin01 there is a helper script create_keys.sh and an openssl config file openssl.cnf which will help you to get rid of most of the typing for producing the required certificate request files for new machines.

Renewing certificates

Currently renewing a certificate involves again filling out a complete registration request. I reuse the old server keys and just copy again the old CSR files into the forms. If you want to see the content of a CSR file you can run the command:

openssl req -in ./t3se02.psi.ch-csr.pem  -text

LDAP certificates

on t3admin node produce a certificate for LDAP server:

cd /root/clusteradmin/etc/cluster-ca/pki/certs/ 

check README, save old certificate

and run

./cluster-ca.sh -r ./pki -s t3ldap01.psi.ch 

scp  /root/clusteradmin/etc/cluster-ca/pki/certs/t3ldap01.psi.ch-cert.pem t3ldap01:/etc/pki/tls/certs/slapd-cert.pem

In addition ensure that the CA root cert is still OK:

openssl x509 -in /etc/openldap/certs/08a2f47c.0  -text -noout

on LADP node:

One may precise certificate location in /etc/openldap/slapd.conf

Confirm that it is the active certificate:

penssl x509 -in /etc/pki/tls/certs/slapd-cert.pem  -subject -dates -noout 

and restart ldap to make it reread its certificate and key:

/etc/init.d/ldap restart

from UI node test whether the certificate is active in the service by executing:

echo | openssl  s_client  -connect  t3ldap01.psi.ch:636 2 > /dev/null | openssl x509 -subject -dates -noout

Information in relation to earlier problems with SWITCH certificates

Problem 2: Some services (e.g. myproxy) have/had problems with the certificates for PSI, since the certificates for PSI contain parentheses in the DN ( O=Paul-Scherrer-Institut (PSI)), and the services had errors in the routines that did DN string comparisons. Probably the programmers had not taken into account that parentheses are valid characters in a DN, and failed to treat them correctly in the regexp comparisons.

Problem 1: The new switch certificates that are issued by QuoVadis, no longer have the email in the dn, so we should no longer see compatibility problems with some Grid services.
The DN of the PSI certificates contains parentheses for the "(PSI)" part. This is not correctly parsed in some text matching functions (e.g. myproxy server) causing authentication failures (this is the result of a tough debugging marathon with Maarten Lithmaat in Dec of 2009)

Note: Due to a complex signing-policy configuration file, the SWITCH certificates showed problems in the past with certain non standards compliant services (quite a few). We need to test for dcache client compatibility and else get certificates from the LCG catch all CA at DOEGrids. However this entails defining a Registration Agent for PSI (see here).

First tests with dcache clients indicated that the SWITCH host certificates are ok for gridFTP and SRM protocols. gsidcap write fails due to space management problems not related to this, it seems.

Initial version: -- DerekFeichtinger - 13 Aug 2008