SHA-2 readiness testing by WLCG VOs

This page describes how services used by WLCG VOs (alice, atlas, cms, dteam, lhcb, ops) can be tested for SHA-2 readiness.

Mailing list for technical discussions: (subscribe here)


Please refer to RFC proxy and SHA-2 signature support for the rationale.

Task tracking

New VOMS servers

Task Deadline Progress Affected VOs Affected Sites Comments
site service config Sep 15 done all all last ticket verified Oct 28
SAM preprod tests Aug 28 done all all  
SAM prod switch Sep 16 done all all  
check workflows Oct 15 done ALICE all new servers being used across WLCG
check workflows Nov 19 done ATLAS -  
check workflows Nov 24 done CMS - AFS UI and CVMFS UI fixed on Nov 26
check workflows Nov 19 done LHCb -  

RFC proxies

Task Deadline Progress Affected VOs Affected Sites Comments
SAM tests   blocked by SAM-Nagios proxy refresh bug all + ops all  
VO tests   CMS users already use RFC proxies;
ATLAS need a newer HTCondor (see here)
all all  

As of July 2014 the remainder of this page should no longer matter.


The CERN CA admins have created a new CA from which VO experts (in fact, all CERN users) can obtain SHA-2 certificates:

SHA-2 VOMS server

CERN's official VOMS servers can generate proxies for SHA-2 certificates and new users with such a certificate can also register into their VO via the corresponding VOMRS interface (since the upgrade to EMI-3 on Nov 27, 2013).

Users that already appear in their experiment's VO with their SHA-1 certificate can connect to VOMRS using that SHA-1 certificate in the browser and add their SHA-2 certificate as a secondary certificate:

  • Connect to VOMRS:
  • Click on the + sign before Member Info
  • Click on the + sign before Certificates
  • Click on Add Certificate
  • Click on the Search button
  • Scroll the horizontal scroll bar to the right to reveal the fields New DN, New CA and Reason
  • Paste the new DN in X509 format (with slashes as separators, as usual)
    • for CERN users the DN stays the same
  • Select the corresponding CA from the drop-down menu
    • for CERN users the new CA is the CERN Grid CA
  • Put a reason in the Reason field (e.g. Added SHA-2 cert)
  • Click on the Submit button
  • an e-mail should confirm the addition of the secondary certificate
  • a VO manager then needs to approve it before it can be used

The remainder of this page is about the SHA-2 readiness testing that was done in 2013.

If you cannot use the official servers for some reason, a temporary VOMS server has been set up to register VO expert SHA-2 certificates (from any CA) in the corresponding VOs. These pages should be accessible also from outside CERN:

A number of VO experts at CERN have been pre-registered already. To register another certificate, load it in your browser and follow the instructions on the page for your VO. Note: the registration currently gets stuck at the first stage, the applicant does not receive the confirmation e-mail. Just contact Maarten by e-mail to get the registration finished.

Installing the new CA

The new CA is part of IGTF since version 1.54, released June 24 and made available to EGI sites on June 25. The relevant rpms are:

They need to be installed on any service to be tested with certificates from the new CA and also on the UI on which corresponding VOMS proxies will be created or used, else e.g. GridFTP data transfers would fail.

Installing support for the SHA-2 VOMS server

Note: this section only applies if the temporary SHA-2 VOMS server is used.

Any service to be tested with SHA-2 VOMS proxies first needs to support the SHA-2 VOMS server. The UI is also affected, otherwise certain commands may complain about the VOMS proxies, or even fail altogether.

To avoid the need for reconfiguration, the service admin can simply install one of the following rpms or just copy the VOMS server host certificate into /etc/grid-security/vomsdir (or $X509_VOMS_DIR on relocated installations):

Creating SHA-2 VOMS proxies

If CERN's official VOMS servers are used:

$ voms-proxy-init -voms ..... -cert .globus/sha2-cert.pem -key .globus/sha2-key.pem

The rest of this section applies if the temporary SHA-2 VOMS server is used.

Add the special VOMS server with a convenient nickname to the list of known servers, for example like this:

$ mkdir -p ~/.glite
$ cat >> ~/.glite/vomses << EOF
"sha2" "" "port" \
"/DC=ch/DC=cern/OU=computers/" "xyz" "24"

Replace port with the port number and xyz with the name of your VO. Mind all the quotes!

The ports are:

  • 15000 - alice
  • 15001 - atlas
  • 15002 - cms
  • 15003 - lhcb
  • 15004 - dteam
  • 15009 - ops

Then create a proxy e.g. like this:

$ voms-proxy-init -voms sha2 -cert .globus/sha2-cert.pem -key .globus/sha2-key.pem

$ voms-proxy-init -voms sha2:/xyz/Role=lcgadmin -cert .globus/sha2-cert.pem \
  -key .globus/sha2-key.pem

Testing service readiness

Any service applying authorization based on certificates should be tested for SHA-2 readiness. Here we are mostly concerned with VO-specific services. Compliant versions of generic middleware services have been released by EMI and OSG, and their uptake will be tracked by EGI and OSG.

To test the readiness of a service it should be sufficient to try each of its protocol interfaces with a SHA-2 proxy or certificate (e.g. loaded in the browser):

  • if the authorization works, the corresponding code is compliant and no upgrade would be needed
  • if the authorization fails, the configuration may be incorrect or the corresponding code does not support SHA-2 and would need to be upgraded

Stress tests should not be needed in this matter.

Try with a recent UI version

On the latest EMI-2 and -3 UI versions voms-proxy-init uses the same algorithm as the one found in the user certificate (here: SHA-2), whereas in older versions SHA-1 is hardcoded. It would be best to ensure the relevant services can handle proxies created by the most recent VOMS versions, which should also cover older versions that may still be in use for a while.

Currently a pre-configured EMI-2 UI is available in the certification testbed:


One could create the proxy on that host and copy it to a machine that has the correct environment for testing VO services. A number of VO experts have their AFS accounts enabled already, others can contact Maarten to get access.

Edit | Attach | Watch | Print version | History: r18 < r17 < r16 < r15 < r14 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r18 - 2014-11-28 - MaartenLitmaath
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LCG All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2023 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback