EGI IGTF Release

From EGIWiki
Jump to: navigation, search

To ensure interoperability within and outside of EGI, the Policy on Approved Certification Authorities defined a common set of trust anchors ("Certification Authorities" or "CAs") that all sites in EGI should install. In short, all CAs accredited to the Interoperable Global Trust Federation under the classic, MICS or SLCS Authentication Profiles are approved for use in EGI. Of course, sites may add additional CAs as long as the integrity of the infrastructure as a whole is not compromised. Also, if there are site or national policies/regulations that prevent you from installing a CA, these regulations take precedence -- but you then must inform the EGI Security Officer (see EGI CSIRT:Main Page) about this exception.


Version 1.81 - change log and information

The change log contains important notices about the release, as well as a list of changes to the trust fabric.


To install the EGI trust anchors on a system that uses the RedHat Package Manager (RPM) based package management system, we provide a convenience package to manage the installation. To install the currently valid distribution, all RPM packages are provided at

The current version is based on the IGTF release with the same version number. Install the meta-package ca-policy-egi-core and its dependencies to implement the core EGI policy on trusted CAs.

Using YUM package management

Add the following repo-file to the /etc/yum.repos.d/ directory:


and then update your installation. How to update depends on your previous activity:

yum clean cache metadata 
yum update lcg-CA 
and you are done. This will update the packages installed to the latest version, and also install the new ca-policy-egi-core package as well as a ca-policy-lcg package. All packages encode the same set of dependencies
yum update ca-policy-egi-core
although at times you may need to clean the yum cache using yum clean cache metadata
yum install ca-policy-egi-core

Using the distribution on a Debian or Debian-derived platform

The 1.39+ releases experimentally add the option to install the trust anchors from Debian packages using the APT dependency management system. Although care has been taken to ensure that this distribution is installable and complete, no guarantees are given, but you are invited to report your issues through GGUS. You may have to wait for a subsequent release of the Trust Anchor release to solve your issue, or may be asked to use a temporary repository. To use it:

wget -q -O - \ \
     | apt-key add -
#### EGI Trust Anchor Distribution ####
deb egi-igtf core
apt-get update
apt-get install ca-policy-egi-core

Using the distribution on other (non-RPM) platforms

The trust anchors are provided also as simple 'tar-balls' for installation on other platforms. Since there is no dependency management in this case, please review the release notes carefully for any security issues or withdrawn CAs. The tar files can be found in the EGI repository at

Once you have downloaded the directory, you can unpack all the CA tar,gz as follows to your certificate directory:

for tgz in `ls <ca download dir>`; do tar xzf <ca download dir>/$tgz --strip-components=1 -C /etc/grid-security/certificates; done

Installing the distribution using Quattor

Quattor templates are povided as drop-in replacements for both QWG and CDB installations. Update your software repository (re-generating the repository templates as needed) and obtain the new CA templates from:

Make sure to mirror (or refer to) the new repository at and create the appropriate repository definition file.

For wLCG sites that are migrating from the lcg-CA package: the wLCG policy companion of the EGI templates can be found at (QWG) and (CDB) and can be included in the profile in parallel with the EGI core template. All packages needed are also included in the EGI repository, so only a single repository reference is necessary.

New distribution format (OpenSSL1 dual-hash mode)

The EGI release uses a new format in which to distribute the trust anchors. In OpenSSL version 1.0, as released for example in RedHat Enterprise Linux 6, Fedora Core 12+, or Debian5, the characteristic hash format ("HHHHHHHH.0") has changed. Although it superficially looks the same, each CAs gets a different hash in OpenSSL1 as compared to OpenSSL 0.x, or as compared to BouncyCastle or gLite TrustManager. Please review the EUGridPMA news letter of February 15 for full technical details.

To accommodate this changed hash format, the new distribution uses symbolic links for both hashes, that jointly refer to the same physical file with the CA certificate, called alias.pem. This ensures that the new trust anchor distribution works with both format simultaneously. You can install this distribution on all platforms (both OpenSSL1 as well as OpenSSL0.x) and both are supposed to work.

However, old version of fetch-crl (the 2.x) series will retrieve CRLs for one version of OpenSSL only, namely the version which is used by fetch-crl itself when it is run. To get CRLs downloaded for both versions of OpenSSL

Trust Anchor structure for differentiated (collaborative) assurance

EGI is moving towards support for 'differentiated' or collaborative assurance, where different elements of trust are provided by several collaborating parties: the identity providers, user home organisations, and research communities. This means that trust anchors with varying trust assurance profiles will be distributed for use in distinct EGI usage scenarios. Starting mid-2017 (release 1.82 or above) initially two profiles will be supported. For a discussion on the impact, see EGI document 2745.

Notice for sites in EGI that support WLCG

The WLCG collaboration - having so requested EGI and in line with long-term EGI developments in AAI - has included a specific CA to its own trust anchor distribution. Sites that are also part of WLCG should install BOTH the "egi-core" AND "lcg" meta-packages, according to your policies. Note that your organisation or NGI may also have a specific policy and may have added or removed CAs compared to the EGI core policy. Sites that need compliance with the WLCG policy should install BOTH packages, or you will miss out the CERN WLCG IOTA CA specific exception see EGI document for details and the WLCG statement for the WLCG specific decision.

The EGI production repository contains all relevant packages for both policies (and the WLCG repository contains also all EGI packages). There is no reason to reconfigure repository locations. Specifically installing (adding) also the ca-policy-lcg package may be necessary for system configurations built after May 2009.

Combined Assurance/Adequacy Model

In the first quarter of 2017, full support for differentiated assurance profiles (combined assurance/adequacy model, also called "cam") will be introduced in the EGI trust fabric infrastructure. This will take the form of an additional trust anchor meta-package, and replaces the specific policy mechanism described above. Such full support also required new software and configuration at each resource centre. You must deploy the additional trust anchor meta-packages and the new local policies in unison, and never install the cam package without such software support.

Implementation notes for trust anchor releases post 1.82

The following does not apply to current production releases - it is exclusive to the technology preview

Not installing the new package does not have any detrimental effect on current users - only a new class of users (that can only obtain an opaque identifiers and do not do full vetting at their electronic identity provider) could be affected, and then only those users that are member of one of the communities that has part of the combined-assurance programme: LCG-Atlas, LCG-Alice, LCG-LHCb, and LCG-CMS.

Also technically this means that you must only install the new ca-policy-egi-cam packages if you also at the same time implement VO-specific authorization controls in your software stack. This may require reconfiguration or a software update:

for dCache 
full support is expected in release v3.1. Meanwhile, if you support enumerated communities for at the DOGWOOD assurance level, you can upgrade to at least release 2.16 and configure negative controls to limit the set of acceptable VOs for those prinicpals whose credential policy OID equals 1.2.840.113612. See for details or ask your software provider. In future releases, differentiated access to storage based on the assurance level can be added - for now decisions are best implemented as binary choices (either 'in' or 'out')
for gLExec/LCMAPS 
all necessary software is included in UMD-3 and UMD-4, for EL6, EL7, and Debian-based distributions. You can use the example configuation file included in the ca-policy-egi-cam package under /usr/share/doc and see for more details the VO-CA-AP Wiki. Authorization based on VO and CA combinations are binary (either 'in' or 'out')
for Argus 
no vendor provided solution is available at this time. Contact your software vendor for support

When in doubt just only install the regular ca-policy-egi-core package. There are no changes in this case. The ca-policy-egi-core package is approved for all VOs membership and assurance models.

Patches and work-arounds

mod_ssl renegotiation timeouts

We provide here a workaround for the issue summarised in comment #57 of bug #48458. The following rpm has been added to the repository: dummy-ca-certs-20090630-1.noarch.rpm. Please note that:

For Quattor (QWG and CDB) setups, add


to your templates, preferably in a file different from the automatically-generated egi-ca-policy-core.tpl template.

Reminder notice for VOMS AA operators

Several updates to this trust anchor distribution incorporate changes to the name of the issuing authority, but the name of the end-entities and the users remains exactly the same. To make the change transparent, all operators of VOMS and VOMS-Admin services are requested to enable the subject-only name resolution mechanisms in VOMS and VOMS Admin

Concerns, issues and verification

If you experience problems with the installation or upgrade of your trust anchors, or with the repository, please report such an issue through the GGUS system. For issues with the contents of the distribution, concerns about the trust fabric, or with questions about the integrity of the distribution, please contact the EGI IGTF liaison at

You can verify the contents of the EGI Trust Anchor (CA) release with those of the International Grid Trust Federation at, or its mirror at See the IGTF and EUGridPMA web pages for additional information.

Make sure to verify your trust anchors with TACAR, the TERENA Academic CA Repository, where applicable.

Personal tools