Sounds good
to me. It would be good to hear from Rob on this one, he
has been
thinking through the network issues.
-
prateek
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.
|