I'd
prefer HOST.VENDOR.com, where HOST is up to the vendor and VENDOR is oblix,
netegrity, etc. This is similar to the original proposal except for the choice
of HOST.
--
Charles
No
problem here... After spending some time looking at subjectAltName (and
browser caveats), I think this is a good idea.
Ryan
Agreed,
this is an issue that obviously wasn't completely thought through in the
draft-03. But then again, this is why we are having a rehearsal
:)
The point
is that you cannot "alias" an SSL server when doing GET
//https:<domain-name>. The client should (and in case of a browser)
does insist on a match between the certificate CN and the
<domain-name>. This is also the case with the SAML requester and
responder.
Rob, is
there really a problem here? The whole point of having distinct
<domain-names> was to aid demonstration. Many people have already
indicated that they cannot support such a scheme. Is there really any issue
if the URLs all take the form -
http(s):.//netegrity.server.com:443/inter-site-transfer
http(s)://netegrity.server.com:443/destination-artifact-receiver
etc.
I don't
really see the issue. If so, I guess people may have to re-publish
their
URLs
(keeping in mind the SSL issue).
Is this a
big deal?
-
prateek
Perhaps a bit late to bring this up, but wouldn't this problem be
avoided if we used the "real" machine names in all URLs. My
implementation (currently) requires that the InterTransfer Service and the
Responder Service to run on the same web server, but the demo requires
these two have URLs with different hosts:
I cannot get a certificate with a CN that works for both of these
URLs. I also don't think I can generate a certificate request from my
iPlanet admin interface that includes subjectAltNames. But if I could use
the same host name for both of these URLs, say oblx-2ks2.oblix.com, I
could use that host name in the certificate.
-- Charles
I haven't done
a lot of this stuff, but I didn't think this should be
necessary.
If I'm not
mistaken, when you request your cert, you should specify the actual
system host name (e.g. jackson.rsa.com) as the Common Name, not
something like "www.crosslogix.com". It is
the cert not matching the system name that causes the complaint. I
don't believe it has anything to do with "portal", receiver",
etc.
-----Original
Message----- From:
Tahura Chaudhry [mailto:Tahura.Chaudhry@baltimore.com] Sent: Thursday, June 13, 2002 3:12
PM To: Mingde Xu; 'Ryan
Eberhard'; saml-dev@lists.oasis-open.org Subject: RE: [saml-dev] URGENT: A
"plan" for the CA... Instructions for ob taining the
certs
You can include multiple names in
the "subjectAltName" field of a certificate to get around this
problem.
-----Original
Message----- From:
Mingde Xu [mailto:mxu@crosslogix.com] Sent: Thursday, June 13, 2002
3:08 PM To: 'Ryan
Eberhard'; saml-dev@lists.oasis-open.org Subject: RE: [saml-dev] URGENT: A
"plan" for the CA... Instructions for ob taining the cer
ts
The browser
does complain "The name on the security certificate does not match the
name of the site".
To skip this
error message in the web browser, it is required that the site name
and CN are the same. In that case, different site (such as
portal.xxxx.com, application.xxxx.com) must use different certificate
as you suggested.
Does anyone
have any idea how we handle this matter?
-----Original
Message----- From:
Ryan Eberhard [mailto:ryan.eberhard@entegrity.com] Sent: Thursday, June 13, 2002
11:07 AM To:
saml-dev@lists.oasis-open.org Subject: RE: [saml-dev] URGENT:
A "plan" for the CA... Instructions for ob taining the cer
ts
Does anyone
know the rules for specifying the CN attribute in the certificate
request so that browsers will not complain about machine name
mismatches? For instance, I see that the Crosslogix's
certificate request uses a CN of www.crosslogix.com, but the
URL's hit by a browser will include machine names of
"portal.crosslogix.com" and
"receiver.crosslogix.com".
Won't this
cause a browser to complain? We will likely have the same
issue with "portal", "receiver", and "responder" in the
.entegrity.com domain.
-----Original
Message----- From: Mingde Xu
[mailto:mxu@crosslogix.com] Sent: Thursday, June 13, 2002
12:30 PM To:
'Philpott, Robert'; saml-dev@lists.oasis-open.org Subject: RE: [saml-dev]
URGENT: A "plan" for the CA... Instructions for ob taining the cer
ts
Attached
is the CrossLogix certificate request, for both server and
client usage.
FYI: We
are able to use Baltimore Trial Certificate obtained through this
certificate request.
This footnote confirms that this email message has
been swept by
MIMEsweeper for the presence of computer
viruses.
-----------------------------------------------------------------------------------------------------------------
The information contained in this message is
confidential and is intended
for the addressee(s) only. If you have received this
message in error or
there are any problems please notify the originator
immediately. The
unauthorised use, disclosure, copying or alteration
of this message is
strictly forbidden. Baltimore Technologies plc will
not be liable for
direct, special, indirect or consequential damages
arising from alteration of the
contents of this message by a third party or as a
result of any virus being
passed on.
This footnote confirms that this email message has
been swept for Content Security threats,
including
computer
viruses.
http://www.baltimore.com
This footnote confirms that this email message has
been swept by
Baltimore
MIMEsweeper for Content Security threats,
including
computer
viruses.
|