I agree
with the recommended changes. So does everyone agree that we will now use:
<host>.<company>.com[:port]/<target_path>
for our
URL's?
ACTION ITEM FOR ALL (except Sun and Oblix):
Could everyone please cut/paste the following "form" into a message
and send it to the list with the subject "NEW Interop Configuration Data
for <company name>" - that will make it easier to locate the
info among all the messages. I will collect everyone's NEW configuration
data into a document and hopefully get it out sometime tomorrow.
I have seen updated information from Sun
and Oblix that follows the new rules and the info is close to this format. So you
folks don't need to resend it in this format.
Machine Names/IP Addresses - You need
server certs for at least one of these systems:
-
<host-1>.<vendor>.com
192.168.16.xxy
-
(etc)
URLs:
-
Portal:
http<s>://<host-n>.<vendor>.com[:port]/<portal_path>
-
Application: http<s>://<host-n>.<vendor>.com[:port]/<application_path>
-
Inter-Site-Transfer: https://<host-n>.<vendor>.com[:port]/<isx_path>
-
Receiver: https://<host-n>.<vendor>.com[:port]/<receiver_path>
-
Responder: https://<host-n>.<vendor>.com[:port]/<responder_path>
SourceID:
-
Hex: <40-character hex
string>
-
B64: <Base64
string>
Issuer: <string>
Now my thoughts...
Sorry I wasn't around for the "fun"
discussion this afternoon. It sounds more fun than coaching my son's
baseball playoff game (14-16 year olds) ... NOT! Anyway, where
were we?
Jeez, we REALLY didn't think this
through, did we?
As I mentioned, the details of using PKI with
web servers had gotten a bit fuzzy for me. Sadly, it's all coming
back to me now. So, yes we really do need to change the interop or we'll
have a mess of a time getting this set up.
The recommended changes to the URL's
should solve the problem. Unfortunately for some, it means requesting new certs
and reconfiguring your servers a bit.
To answer Minge's question, no, this
doesn't mean you'll need everything on one server. But if any
of the secured URLs are on different systems, those systems will need their own
certs of course.
And now we can even stick with default http
and http ports if we want to. It will also considerably simplify the DNS server
configuration
ACTION ITEM FOR ALL: Please cut/paste the
following "form" into a message and send it to the list with the
subject "NEW Interop Configuration Data for <company name>" -
that will make it easier to locate the info among all the messages. I will
collect everyone's NEW configuration data into a document and hopefully
get it out sometime tomorrow.
Now I'm off to reconfigure my web
servers and SAML components and ... (sigh).
-----Original Message-----
From: Mingde Xu
[mailto:mxu@crosslogix.com]
Sent: Thursday, June 13, 2002 6:56
PM
To: 'Mishra, Prateek'; 'Charles
Knouse'; Philpott, Robert; Tahura Chaudhry; 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
Does this mean portal,
inter-site-transfer, responder, receiver, and application have to run in a
single machine? For example, "netegrity.server.com"
can be pointed to one machine only.
-----Original Message-----
From: Mishra, Prateek
[mailto:pmishra@netegrity.com]
Sent: Thursday, June 13, 2002 1:38
PM
To: 'Charles Knouse'; Philpott,
Robert; Tahura Chaudhry; 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
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
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).
-----Original Message-----
From: Charles Knouse
[mailto:cknouse@oblix.com]
Sent: Thursday, June 13, 2002 4:05
PM
To: Philpott, Robert; Tahura
Chaudhry; Mingde Xu; Ryan Eberhard; saml-dev@lists.oasis-open.org
Subject: RE: [saml-dev] URGENT: A
"plan" for the CA... Instructions for obtaining the certs
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.
-----Original Message-----
From: Philpott, Robert
[mailto:rphilpott@rsasecurity.com]
Sent: Thursday, June 13, 2002
12:52 PM
To: 'Tahura Chaudhry'; Mingde Xu;
'Ryan Eberhard'; saml-dev@lists.oasis-open.org
Subject: RE: [saml-dev] URGENT: A
"plan" for the CA... Instructions for obtaining the certs
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.