OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [saml-dev] URGENT: A "plan" for the CA... Instructions for obtaining 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
 
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
-----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.
 
-- Charles
-----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.

 

Rob Philpott

RSA Security Inc.

The Most Trusted Name in e-Security

Tel: 781-515-7115

Mobile: 617-510-0893

Fax: 781-515-7020

mailto:rphilpott@rsasecurity.com

 

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC