Chrome and browser signing
The Chrome developers have been working on adding keygen-support as it was previously present in Mozilla Firefox, Opera and Apple Safari to Chromium.
Chrome 5 seems to support the keygen tag on all major platforms. However, enrollment success feedback is sometimes still suboptimal. But we can use the same mechanisms as for other browsers to support browser certificate enrollment for users running Google Chrome.
Problems with MacOS X
At the time of writing this, the Comodo CA could not decode CSRs created by Chrome on MacOS X. As there seems to be a history to this problem and the user base of Chrome on MacOS X is not estimated to be very high, currently this remains unfixed. If you feel very strongly that browser requests should work with Chrome on MacOS X, please drop us a line at tcs-portal-core [at] terena.org. Otherwise it is recommended to use Safari for the time being. Thanks.
A Chromium issue tracks limitiations of the response format. Currently only DER encoding is supported on all platforms with Chrome.
Managing the enrolled certificate (Windows)
Chrome makes use of Windows' certificate management facilities. That means that processed and installed certificates are handled the same way as with Internet Explorer enrollment.
Managing the enrolled certificate (Linux)
Instead of having it's own certificate management facilities, on Linux Google chrome ties into libnss3-tools. See the Chrome documentation on certificate management. On the downside, users will not have a very nice graphical interface to manage their certificates. On the other downside, the certutil command is not very easy to use. On the upside, it is rather powerful.
So after issuing a certificate, it can be checked whether it is present as one of the user's certificates:
tzangerl@hawaii:~$ certutil -d sql:$HOME/.pki/nssdb -L
Certificate Nickname Trust Attributes
Confusa Test User Full Name aeoeaa firstname.lastname@example.org's TERENA eScience Personal CA ID u,u,u
Unfortunately the auto-generated cert id makes all cert operations an input-hazzle. List the details of a certificate:
tzangerl@hawaii:~$ certutil -d sql:$HOME/.pki/nssdb -L -n Confusa\ Test\ User\ Full\ Name\ aeoeaa\ email@example.com\'s\ TERENA\ eScience\ Personal\ CA\ ID
Version: 3 (0x2)
Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
Issuer: "CN=TERENA eScience Personal CA,O=TERENA,C=NL"
To export the certificate, from the NSS3 database, pk12util has to be used because certutil can only export the public key:
tzangerl@hawaii:~$ pk12util -d sql:$HOME/.pki/nssdb -o cert.p12 -n Confusa\ Test\ User\ Full\ Name\ aeoeaa\ firstname.lastname@example.org\'s\ TERENA\ eScience\ Personal\ CA\ ID
Enter password for PKCS12 file:
pk12util: PKCS12 EXPORT SUCCESSFUL
Now that the certificate has been exported in PKCS#12 format, it needs to be converted to PKCS#7 format in order to be used with the Globus/Grid software:
openssl pkcs12 -nocerts -in cert.p12 -out ~user/.globus/userkey.pem
openssl pkcs12 -clcerts -nokeys -in cert.p12 -out ~user/.globus/usercert.pem
chmod 0600 userkey.pem
chmod 0644 usercert.pem
Importing the CA certificate (Windows)
Automatic import via the Chrome browser does not work. Instead the certificate has to be downloaded to the harddrive. Opening the browser options, navigating to "Under the hood" and clicking on the "Certificate Management" button, will bring up Windows' integrated certificate management. There the certificate can be imported.
Importing the CA certificate (Linux)
Our friend CertUtil will have to help us with importing again. First we download the CA-cert from the CA section of the portal and then we import it with certutil. -t T,c,c tells cert-util that the certificate can serve as a well CA for client certificates in SSL and is a valid CA for S/MIME and JAR.
tzangerl@hawaii:~/Downloads$ certutil -d sql:$HOME/.pki/nssdb -A -n terena_escience_ca -t T,c,c -i TERENAeSciencePersonalCA.crt