Hi, There looks to be a changed in behavior with globus-gssapi-gsi Reporting on behalf of David Cameron on behalf of Gerd Behrmann. They fail because the client rejects our hostcert for srm.ndgf.org: SOURCE Failed to get source file size: srm-ifce err: Communication error on send, err: [SE][Ls][] httpg://srm.ndgf.org:8443/srm/managerv2: CGSI-gSOAP running on fts105.cern.ch reports Error initializing context GSS Major Status: Unexpected Gatekeeper or Service Name GSS Minor Status Error Chain: globus_gsi_gssapi: Authorization denied: The expected name for the remote host (host@piggy-x.ndgf.org) does not match the authenticated name of the remote host (host@piggy.ndgf.org). This happens when the name in the host certificate does not match the The client resolves the name srm.ndgf.org as used in the URI, a name which does appear in the hostcert’s subjectaltnames. The client is however not satisfied with this as it expects the reverse of the IP that srm.ndgf.org resolves to to appear in the subjectaltnames too. AFAIK this is not a requirement for TLS, not does it appear to be required for the majority of transfers. Thus I wonder why it appears to be a requirement for the above transfers. Is there something special about the CERN FTS involved in those transfers?

There was a change in behaviour in this version. The name matching in globus-gssapi-gsi can be done in 3 different ways. - the old very non-standard behaviour used in GT2 - according to RFC 2818 - a hybrid mode that accepts both of the above The old default was the hybrid mode, the new version now sets the default to RFC 2818. For details see /etc/grid-security/gsi.conf From the description of the of GT2 mode in the above file I think this explains why a subject name of piggy-x was accepted as a match for the host name piggy.