-- AlexanderFedotov - 28-Sep-2010

Links

WorkBookStartingGrid > Obtaining and Installing your Certificate
> SWGuideLcgAccess (How to get access to WLCG)

CERN Certification Authority
> FAQ: Who can request a certificate at CERN CA
> EUGridPMA Clickable Map of Authorities
> http://ca.grid.kiae.ru/RDIG/ : RDIG Certification Authority

• > http://ca.grid.kiae.ru/RDIG/certificates/renew.html : Обновление сертификата
• > http://ca.grid.kiae.ru/RDIG/certificates/obtain.html : Получение нового сертификата
• > https://ca.grid.kiae.ru/RDIG/requests/request-cycle.html
  Инструкция по созданию запроса на сертификат
  a local copy: a pdf snapshot 28.09.10

Russian Grid User Support : http://ussup.itep.ru/
> S chego nachat'? :

• instruction on how to convert certificate from .pem format to .p12

openssl pkcs12 -export -inkey userkey.pem -in usercert.pem -out my_cert.p12 -name "My certificate" 
     

• instruction on how to load .p12 certificate into russified firefox 1.02 .
  For other browsers see: http://lcg.web.cern.ch/lcg/loading_certifs.htm (Worldwide LHC Computing Grid: Loading Certificates into Browser)
• additional info: http://grid.sinp.msu.ru/grid/roc/user_reg (EGEE-RDIG Operations Centre)

A procedure to renew the user certificate

Step 1: Sending an initial request

Go to https://ca.grid.kiae.ru/RDIG/requests/new-user-cert.html , fill a form, send it.

Result: you get

• a shell script user_cert-request.sh
• a pdf file with a certificate request form , user_cert-form.pdf, which you will print, fill later, and bring in person to a Registration Authority (RA = Lyublev in our case)

Step 2: Running the script user_cert-request.sh

This is described in detail in https://ca.grid.kiae.ru/RDIG/requests/request-cycle.html

$ sh user_cert-request.sh

A "dialogue" follows, where you will have to enter a pass phrase for your private key which will be generated:

[dom2] ~/private/grid/2010 $ sh user_cert-request.sh

------------------------------------------------------------------------
Creating the cryptographic keypair for your certificate. The file named
   /home/fedotov/.globus/userkey.20100928-031203.pem
will contain your private key. This file must not be shared with anyone
and must be kept in a safe place. Never transfer your private key using
plain communication channels (email, telnet sessions, ftp and so on).

Choose strong password for your private key. Remember, CP/CPS states
that the password should be at least 15 characters long.

If you will forget your password no one will help you: your
certificate will become useless.

                           NEVER USE EMPTY PASSWORD!
              NEWER STORE YOUR PASSWORD ALONG WITH THE PRIVATE KEY!
------------------------------------------------------------------------
Press [Enter]...

Generating a 1024 bit RSA private key
................................++++++
.....................++++++
writing new private key to '/home/fedotov/.globus/userkey.20100928-031203.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
------------------------------------------------------------------------
All done. Your private key is stored in the file
   /home/fedotov/.globus/userkey.20100928-031203.pem

Now you should send the message, contained in the file
   /home/fedotov/.globus/userreq.20100928-031203.mail
to
   rdig-ca@grid.kiae.ru
You will be mailed back with the serial number of your request. Then
you should completely fill the paper request form and go to your
Registration Authority to complete your request. You will need your
public key modulus:
   C36CC845BA 16113627613E87BE1BC048BF749ECCE33D5108F688D245A2F710CE0CF4FC008E3EEAA159423991220EAC5B96C1CA6DF8C72BCF5E96F878C35F23E278563F3E39849124C19A7C756D93B3D5A70B470D4191473943524D3904B9C22F059AF6C1B162E45E1C4DE59DDBBC478CA43D4056722CE4B8B7983E 9A3BB37C95
10 starting digits and 10 ending digits of modulus was separated by
spaces from the rest of the digits for your convinience.

Your private key and certificate have non-standard names to avoid
overwriting of your current files. When you will get your certificate
you should backup your current certificate and the private key and
overwrite them with the new files.
------------------------------------------------------------------------
Press [Enter]...
[dom2] ~/private/grid/2010 $ 

The results are:

• file /home/fedotov/.globus/userkey.20100928-031203.pem
  with the generated private key .
  "This file must not be shared with anyone and must be kept in a safe place. Never transfer your private key using plain communication channels (email, telnet sessions, ftp and so on)."
• The chosen secret password for the private key .
  "Choose strong password for your private key. Remember, CP/CPS states that the password should be at least 15 characters long.
  If you will forget your password no one will help you: your certificate will become useless.
  NEVER USE EMPTY PASSWORD!
  NEWER STORE YOUR PASSWORD ALONG WITH THE PRIVATE KEY!
• file /home/fedotov/.globus/userreq.20100928-031203.mail
  containing a message to be sent via e-mail to rdig-ca@gridNOSPAMPLEASE.kiae.ru . It looks like

  yaCA-request-type: certification
  yaCA-cert-type: user
  yaCA-user-first-name: Alexander
  yaCA-user-last-name: Fedotov
  yaCA-user-email: Alexander.Fedotov@cern.ch
  yaCA-user-contact-phone: +7 (495) 333-90-61
  -----BEGIN CERTIFICATE REQUEST-----
  . . .
  -----END CERTIFICATE REQUEST----- 

• the public key modulus (whatever it means... see the dialogue), whose "10 starting digits and 10 ending digits" will have to be copied into the printed request form.
• the file usercert.20100928-031203.pem, where the certificate obtained later will have to be copied to. So far it contains the instruction:

  The issued certificate should be placed here. The corresponding key file is
    /home/fedotov/.globus/userkey.20100928-031203.pem
  You can always check if your certificate and your private key do correspond to
  each other by issuing two commands
    /usr/bin/openssl rsa -in /home/fedotov/.globus/userkey.20100928-031203.pem -noout -modulus:
    /usr/bin/openssl x509 -in <your-certificate> -noout -modulus
  and check that their outputs are the same.

Step 3: mailing file userreq. ... .mail to rdig-ca@gridNOSPAMPLEASE.kiae.ru

The result:

• you are mailed back:

  Date: Tue, 28 Sep 2010 03:35:36 +0400
  From: rdig-ca@grid.kiae.ru
  To: Alexander.Fedotov@cern.ch
  Subject: certification request for
      /C=RU/O=RDIG/OU=users/OU=itep.ru/CN=Alexander Fedotov
  
  Your request was accepted with serial number 2771.
  Use this number as the reference for your request when you will talk
  to your Registration Authority.

  • The serial number 2771 should be copied to the printed request form.

Step 4: Going to the RA (Lyublev).

• print the request form,
• fill it with the modulus (20 alphanumericals), the request number (2771), sign,
• go to Lyublev

The results:

• The RA approves the request, and communicates with RDIG CA
• RDIG notifies you via e-mail:

  Date: Wed, 6 Oct 2010 10:39:23 +0400
  From: rdig-ca@grid.kiae.ru
  To: Alexander.Fedotov@cern.ch
  Subject: request for /C=RU/O=RDIG/OU=users/OU=itep.ru/CN=Alexander Fedotov
  
  RA message for the request number 2771 was received.
  Processing result: approved
  The reason line is: Data correct.Request approved. 

• Later on, you get a mail with the certificate:

  Date: Wed, 6 Oct 2010 18:10:00 +0400
  From: rdig-ca@grid.kiae.ru
  To: Alexander.Fedotov@cern.ch
  Subject: certificate for /C=RU/O=RDIG/OU=users/OU=itep.ru/CN=Alexander Fedotov
  
  Certificate:
      Data:
      . . .
  -----BEGIN CERTIFICATE-----
  . . .
  -----END CERTIFICATE-----

Step 5: Putting certificate into the file usercert.20100928-031203.pem

• Edit the file and overwrite the old content with the info from the mail, omitting the mail header up to the line Certificate: :

      Data:
  . . .
  -----END CERTIFICATE-----
       

Step 6: Converting certificate from PEM ( .pem ) to PKCS12 ( .p12 ) format

Following the http://ussup.itep.ru/ or http://lcg.web.cern.ch/lcg/loading_certifs.htm instructions:

[dom2] ~/.globus $ openssl pkcs12 -export -inkey userkey.20100928-031203.pem -in usercert.20100928-031203.pem  -out usercert2010.p12 -name "My certificate 2010"
Enter pass phrase for userkey.20100928-031203.pem:
Enter Export Password:
Verifying - Enter Export Password:
[dom2] ~/.globus $

For simplicity the Export Password is made identical to the userkey.pem password (pass phrase).

Result:

• file usercert2010.p12 protected with the password which is identical to the one chosen on Step 2.

Step 7: Loading .p12 certificate into browser

For firefox 3.0.15 , we follow instructions from http://lcg.web.cern.ch/lcg/loading_certifs.htm :

Firefox (version 2.x)

1. Start Firefox (Need an existing "*.p12", and the password for it)
2. Use menu 'Edit' -> 'Preferences' (opens dialog 'Preferences')
3. Select 'Advanced'
4. Click tab 'Encryption'
5. Click button 'View Certificates' (opens dialog 'Certificates Manager')
6. Click tab 'Your Certificates'
7. Click button 'Import' (opens dialog 'File Name to Restore')
8. Browse for '*.p12' file; select it.
9. Click button 'Open' (prompts for password)

Step 8: (optional / just in case) testing your in-browser certificate

Go to http://lcg.web.cern.ch/lcg/cert-trouble.htm (referenced from http://lcg.web.cern.ch/lcg/loading_certifs.htm) and press the `Test Certificate' button.

If the certificate is valid you will see something similar to the following screen:

• Remark 29.11.12. The above links do not work. However, the test button can be found at https://lcg-archive.web.cern.ch/lcg-archive/cert-trouble.htm

• Remark 18.01.15. The above links do not work. However, the test button has been found at http://wlcg.web.cern.ch/getting-started/certificates/test
  The response screen looks like

Step 9: Renaming stuff in .globus directory

There was an instruction in the dialogue on Step 2:

• " Your private key and certificate have non-standard names to avoid overwriting of your current files. When you will get your certificate you should backup your current certificate and the private key and overwrite them with the new files. "

After all the previous steps my .globus contains:

[dom2] ~/.globus $ ls
CERT_VS_KEY_CHECK
mail_with_certificate.2010
mail_with_certificate.gz
usercert.20100928-031203.ORIGINAL_WITH_INSTRUCTIONS.pem
usercert.20100928-031203.pem
usercert2010.p12
usercert.p12
usercert.pem
userkey.20100928-031203.pem
userkey.pem
userreq.20100928-031203.mail
userreq.mail

I would like to

1. replace old (2009) usercert.pem , userkey.pem with the new (2010) versions
2. preserve all the 2009 files by putting `2009' into their names

[dom2] ~/.globus $ rename .20100928-031203 2010 *    # for brevity
[dom2] ~/.globus $ mv mail_with_certificate.gz mail_with_certificate_2009.gz
[dom2] ~/.globus $ mv usercert.p12 usercert2009.p12
[dom2] ~/.globus $ mv usercert.pem usercert2009.pem
[dom2] ~/.globus $ mv userkey.pem userkey2009.pem
[dom2] ~/.globus $ mv userreq.mail userreq2009.mail
[dom2] ~/.globus $ cp -p userkey2010.pem userkey.pem    
[dom2] ~/.globus $ cp -p usercert2010.pem usercert.pem    

Now the status is:

[dom2] ~/.globus $ ls
CERT_VS_KEY_CHECK                            usercert2010.pem
mail_with_certificate_2009.gz                usercert.pem
mail_with_certificate.2010.gz                userkey2009.pem
usercert2009.p12                             userkey2010.pem
usercert2009.pem                             userkey.pem
usercert2010.ORIGINAL_WITH_INSTRUCTIONS.pem  userreq2009.mail
usercert2010.p12                             userreq2010.mail

Then copy the directory to lxplus :

[lxplus255] ~ $ mv .globus .globus2009
[dom2] ~ $ scp -rp .globus lxplus:

Re-register in CMS VO? -- Normally, not.

In SWGuideLcgAccess > How to register in the CMS VO > If are already registered in the CMS VO with a different certificate , one reads:

• "If you have recently obtained a new certificate but you were already registered in the CMS VO with an old certificate, please read also these instructions . This is the case, for example, if you got a new CERN certificate from the new CERN CA but you had already a certificate from the old CERN CA. Basically, what you have to do in this case is to add a new certificate to your entry in the CMS VO."

The above instructions are not quite clear. Looks like one has to re-register only if there are some "cardinal" changes in the certificate.

I did not re-register, and was able to run a CRAB job right after the Step 9 . Though, I did visit the CMS VOMRS server and, while entering, introduced myself with the new certificate -- this may have had played a role...