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.
|