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
m (Changed IGTF name)
(Deprecate and redirect page)
Tag: Replaced
 
(41 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[Category:Security Policy Group (SPG) ]]
[[Category:Security Policy Group (SPG) ]]
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/ Interoperable Global Trust Federation] under the [http://www.eugridpma.org/guidelines/classic classic], [http://www.eugridpma.org/guidelines/MICS/IGTF-AP-MICS-1.2-clean.pdf MICS] or [http://www.tagpma.org/authn_profiles/slcs 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.
{{DeprecatedAndMovedTo|new_location=https://docs.egi.eu/providers/operations-manuals/howto01_using_igtf_ca_distribution/}}
 
= Version 1.74 - change log and information  =
 
The change log contains important notices about the release, as well as a list of changes to the trust fabric.
 
* Review the release notes at [http://repository.egi.eu/sw/production/cas/1/current/meta/ca-policy-egi-core-readme-1.74.txt http://repository.egi.eu/sw/production/cas/1/current/meta/ca-policy-egi-core-readme-1.74.txt]
* 1.74 was released on '''2016-05-28''' as a '''regular''' update
* 1.74 is a '''dual-hash''' (new) style release only
 
== Important 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 [https://documents.egi.eu/document/2745 EGI document https://documents.egi.eu/document/2745] for details and the WLCG statement [http://lcg-ca.web.cern.ch/lcg-ca/doc/WLCG-CERN-IOTA-statement-MB.pdf http://lcg-ca.web.cern.ch/lcg-ca/doc/WLCG-CERN-IOTA-statement-MB.pdf 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.
 
== 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
 
* on the VOMS core Attribute Authority service, configure the "-skipcacheck" flag on start-up. In YAIM this is done by setting "VOMS_SKIP_CA_CHECK" to true. See https://wiki.italiangrid.it/twiki/bin/view/VOMS/VOMSYAIMGuide
* update VOMS-Admin to version >= 3.3.2, and set "voms.skip_ca_check=True" in the service properties. For more info, read the release notes at http://italiangrid.github.io/voms/release-notes/voms-admin-server/3.3.2/
 
= 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 based on the [https://dist.eugridpma.info/distribution/igtf/current/ IGTF release] with the same version number. Install the meta-package <tt>ca-policy-egi-core</tt> and its dependencies to implement the core EGI policy on trusted CAs.
 
== Using YUM package management  ==
 
Add the following [http://repository.egi.eu/sw/production/cas/1/current/repo-files/EGI-trustanchors.repo repo-file] to the <tt>/etc/yum.repos.d/</tt> 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:
 
*'''if you have previously ever installed the <tt>lcg-CA</tt> package''', remove any references to <tt>http://linuxsoft.cern.ch/LCG-CAs/current</tt> from your YUM setup, and run
 
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 <tt>ca-policy-egi-core</tt> package as well as a <tt>ca-policy-lcg</tt> 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 times you may need to clean the yum cache using <tt>yum clean cache metadata</tt>
 
*'''if you are installing the EGI trust anchors for the first time''', run
 
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:
 
*Install the EUGridPMA PGP key for apt:
 
wget -q -O - \
      https://dist.eugridpma.info/distribution/igtf/current/GPG-KEY-EUGridPMA-RPM-3 \
      | apt-key add -
 
*Add the following line to your sources.list file for APT:
 
#### EGI Trust Anchor Distribution ####
deb http://repository.egi.eu/sw/production/cas/1/current egi-igtf core
 
*Populate the cache and install the meta-package
 
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
 
http://repository.egi.eu/sw/production/cas/1/current/tgz/
 
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:
 
*[http://repository.egi.eu/sw/production/cas/1/current/meta/ca-policy-egi-core.tpl http://repository.egi.eu/sw/production/cas/1/current/meta/ca-policy-egi-core.tpl] for QWG
*[http://repository.egi.eu/sw/production/cas/1/current/meta/pro_software_meta_ca_policy_egi_core.tpl http://repository.egi.eu/sw/production/cas/1/current/meta/pro_software_meta_ca_policy_egi_core.tpl] for CDB
 
Make sure to mirror (or refer to) the new repository at http://repository.egi.eu/sw/production/cas/1/current/ 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 [http://lcg-ca.web.cern.ch/lcg-ca/distribution/current/meta/ca-policy-lcg.tpl http://cern.ch/lcg-ca/distribution/current/meta/ca-policy-lcg.tpl] (QWG) and [http://lcg-ca.web.cern.ch/lcg-ca/distribution/current/meta/pro_software_meta_ca_policy_lcg.tpl http://cern.ch/lcg-ca/distribution/current/meta/pro_software_meta_ca_policy_lcg.tpl] (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 [https://www.eugridpma.org/newsletter/eugridpma-newsletter-20100215.txt 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
 
*run fetch-crl 2.x ''twice'', using a different version of OpenSSL each time. Use the <tt>FETCH_CRL_OPENSSL</tt> environment variable to specify an explicit OpenSSL version for use by fetch-crl. This is only needed if you actually use both versions of OpenSSL at the same 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, or download it from [https://dist.eugridpma.info/distribution/util/fetch-crl3/ dist.eugridpma.info]. Fetch-crl 3 can also 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 [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 ca-policy-egi-core, lcg-CA or ca-policy-lcg metapackage dependencies
*If you want to install it you should run: <tt>yum install dummy-ca-certs</tt>
*The RPM contains 60 expired CAs that cannot be used for validation, but will ensure the mod_ssl renegotiation buffer is large enough
 
For Quattor (QWG and CDB) setups, add
 
pkg_repl("dummy-ca-certs","20090630-1","noarch");
 
to your templates, preferably in a file ''different'' from the automatically-generated egi-ca-policy-core.tpl template.
 
== VOMS-ADMIN server does not start (for VOMS-ADMIN service managers only)  ==
'''Note:''' ''This issue affects only the gLite versions of VOMS-ADMIN (up to version 2.5.5), it '''does not''' affect EMI/UMD version of VOMS-ADMIN.''
 
 
A problem has been found where sites upgraded their VOMS server to the latest version of the trust anchors (CA 1.38) and subsequently the VOMS Administrative Interface (VOMS-ADMIN) fails to start. We are presently working to understand the issue. This does not affect the VOMS server itself, but solely the admin interface.
 
'''Please [http://repository.egi.eu/sw/production/cas/1/current-old/README.txt read the full announcement]''' for specific warning and actions that you must take. Changing the repository '''is not recommended to anyone''' except for VOMS ADMIN service managers.
 
The quick fix is for the VOMS server admins to replace the default EGI trust anchor repository by the following temporary repository
 
  http://repository.egi.eu/sw/production/cas/1/current-old/
 
which can be configured using the Yum repo file as described in the special documentation.
 
= 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 egi-igtf-liaison@nikhef.nl.
 
You can verify the contents of the EGI Trust Anchor (CA) release with those of the International Grid Trust Federation at [https://dist.eugridpma.info/distribution/igtf/current/ https://dist.eugridpma.info/distribution/igtf/current/], or its mirror at [https://www.apgridpma.org/distribution/ https://www.apgridpma.org/distribution/]. See the IGTF and EUGridPMA web pages for additional information.
 
Make sure to verify your trust anchors with [https://www.tacar.org/ TACAR], the [http://www.terena.org TERENA] Academic CA Repository, where applicable.

Latest revision as of 14:30, 1 February 2022