Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "EGI IGTF Release"

From EGIWiki
Jump to navigation Jump to search
Line 1: Line 1:
To ensure interoperability within and outside of EGI, the [https://documents.egi.eu/document/83 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 [http://www.igtf.net/ International Grid 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.
= Change log and information on the latest release =


To ensure interoperability within and outside of EGI, the [https://documents.egi.eu/document/83 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 [http://www.igtf.net/ International Grid 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.
The change log contains important notices about the release, as well as a list of changes to the trust fabric. Please review the latest release notes at [http://repository.egi.eu/sw/production/cas/1/current/ca-policy-egi-core-readme-1.37.txt http://repository.egi.eu/sw/production/cas/1/current/ca-policy-egi-core-readme-1.37.txt].


= Installation =
= Installation =
Line 43: Line 46:
* [http://repository.egi.eu/sw/production/cas/1/current/ca-policy-egi-core.tpl http://repository.egi.eu/sw/production/cas/1/current/ca-policy-egi-core.tpl] for QWG
* [http://repository.egi.eu/sw/production/cas/1/current/ca-policy-egi-core.tpl http://repository.egi.eu/sw/production/cas/1/current/ca-policy-egi-core.tpl] for QWG
* [http://repository.egi.eu/sw/production/cas/1/current/pro_software_meta_ca_policy_egi_core.tpl http://repository.egi.eu/sw/production/cas/1/current/pro_software_meta_ca_policy_egi_core.tpl] for CDB
* [http://repository.egi.eu/sw/production/cas/1/current/pro_software_meta_ca_policy_egi_core.tpl http://repository.egi.eu/sw/production/cas/1/current/pro_software_meta_ca_policy_egi_core.tpl] for CDB
= The new OpenSSL1 distribution format =
The EGI release, as of version 1.38, uses a new format in which to distribute the trist anchors. In order to support 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 [https://www.eugridpma.org/newsletter/eugridpma-newsletter-20100215.txt EUGridPMA news letter of February 15] for full technical details.
In short, 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 use dby fetch-crl itself. To get CRLs downloaded for both versions of OpenSSL
* run fetch-crl 2.x ''twice'', using a different version of OpenSSL each time
* upgrade to fetch-crl 3, which has proper dual-hash support as well as many other features. Please refer to [http://www.nikhef.nl/grid/fetchcrl3/ http://www.nikhef.nl/grid/fetchcrl3/] for more information on fetch-crl3. Fetch-crl 3 can be obtained from your standard OS distribution repository (EPEL, Fedora, Debian).


= Patches and work-arounds =
= Patches and work-arounds =
== mod_ssl renegotiation timeouts ==


We provide here a workaround for the issue [https://savannah.cern.ch/bugs/?func=detailitem&item_id=48458#comment57 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:  
We provide here a workaround for the issue [https://savannah.cern.ch/bugs/?func=detailitem&item_id=48458#comment57 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:  
* This rpm is not added to the lcg-CA metapackage dependencies
* This rpm is not added to the lcg-CA metapackage dependencies
* If you want to install it you should run: <tt>yum install dummy-ca-certs</tt>
* If you want to install it you should run: <tt>yum install dummy-ca-certs</tt>

Revision as of 13:47, 26 November 2010

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 International Grid 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.

Change log and information on the latest release

The change log contains important notices about the release, as well as a list of changes to the trust fabric. Please review the latest release notes at http://repository.egi.eu/sw/production/cas/1/current/ca-policy-egi-core-readme-1.37.txt.

Installation

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

http://repository.egi.eu/sw/production/cas/1/current/

The current version is 1.37, 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:

[EGI-trustanchors]
name=EGI-trustanchors
baseurl=http://repository.egi.eu/sw/production/cas/1/current/
gpgkey=http://repository.egi.eu/sw/production/cas/1/GPG-KEY-EUGridPMA-RPM-3
gpgcheck=1
enabled=1

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
  • if you are upgrading from a previous EGI version only, just run
yum update ca-policy-egi-core
although at timmes you may need to clean the yum cache using yum clean cache metadata
  • if you are installing the EGI trust anchors for the first time, run
yum install ca-policy-egi-core

Using the distribution on other 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

http://repository.egi.eu/sw/production/cas/1/current/tgz/

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:

The new OpenSSL1 distribution format

The EGI release, as of version 1.38, uses a new format in which to distribute the trist anchors. In order to support 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.

In short, 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 use dby fetch-crl itself. To get CRLs downloaded for both versions of OpenSSL

  • run fetch-crl 2.x twice, using a different version of OpenSSL each time
  • upgrade to fetch-crl 3, which has proper dual-hash support as well as many other features. Please refer to http://www.nikhef.nl/grid/fetchcrl3/ for more information on fetch-crl3. Fetch-crl 3 can be obtained from your standard OS distribution repository (EPEL, Fedora, Debian).

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:

  • This rpm is not added to the lcg-CA metapackage dependencies
  • If you want to install it you should run: yum install dummy-ca-certs