Important notice concerning the support of TLS v1.2 on EGI ========================================================== Dear colleagues, on Sep 21 a Globus update in the EPEL repositories made TLS v1.2 the only version to be supported for security handshakes in GSI. The concerned package was globus-gssapi-gsi-13.10. Unfortunately, it quickly became clear that a significant number of grid services in EGI are not ready for that change and started running into failures. We therefore asked for the minimum supported version to be set to TLS v1.0 again in /etc/grid-security/gsi.conf: MIN_TLS_PROTOCOL=TLS1_VERSION_DEPRECATED Version globus-gssapi-gsi-14.7-2 has that _temporary_ workaround and is available in EPEL since Oct 16. The UMD currently has globus-gssapi-gsi-13.5 which also is fine for the time being. However, as we still want to be able to exclude TLS < v1.2 in the near future, all potentially affected services should be checked and updated as needed. Such services may directly depend on Globus themselves, but could also be based on Java instead. Of particular concern are SRM, GridFTP, CE and Argus services. Standard SRM services listen on port 8443 (dCache), 8444 (StoRM) or 8446 (DPM), while the BeStMan SRM may listen on a non-standard port. The CREAM CE service listens on port 8443. GridFTP servers used by CREAM, ARC and SE head nodes listen on port 2811, while the port may be unpredictable on SE disk servers. Argus listens on port 8154. To test your SRM, CREAM, Argus or any other HTTPS service, please run a command like this: openssl s_client -tls1_2 -connect HOST:PORT 2>&1 < /dev/null | egrep '^New|Protocol|known|Bad|refused|route' The following output is a sign of _failure_: New, (NONE), Cipher is (NONE) To test a GridFTP server, you normally need a valid VOMS proxy: env GLOBUS_GSSAPI_MIN_TLS_PROTOCOL=TLS1_2_VERSION uberftp HOST pwd If any one of those commands fails due to the TLS v1.2 requirement: please update Java/Globus on the affected service to a recent version, restart the service and try again. For the BeStMan SRM one would need to update the "jglobus" package to version jglobus-2.1.0-10bh available from the EGI third party repository, and restart the service: http://repository.egi.eu/community/software/third.party.distribution/ As JGlobus and BeStMan are both unsupported, please look into replacing such services with alternatives that are supported. We will need to set a deadline for TLS v1.2 support to early 2019 and will let you know when the timeline has become clearer. Please report issues you encounter through GGUS etc.