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.
ellert has edited this update. New build(s): globus-gssapi-gsi-11.18-1.el6. Removed build(s): globus-gssapi-gsi-11.16-1.el6.
This update has been submitted for testing by ellert.
This update is currently being pushed to the Fedora EPEL 6 testing updates repository.
This update has been pushed to testing
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.
ellert has edited this update. New build(s): globus-gssapi-gsi-11.18-1.el6. Removed build(s): globus-gssapi-gsi-11.16-1.el6.
This update has been submitted for testing by ellert.
This update is currently being pushed to the Fedora EPEL 6 testing updates repository.
This update is currently being pushed to the Fedora EPEL 6 testing updates repository.
This update has been pushed to testing
This update has been submitted for stable by ellert.
This update is currently being pushed to the Fedora EPEL 6 stable updates repository.
This update has been pushed to stable