On Thu, Nov 07, 2002 at 11:21:50PM +0100, Richard Levitte - VMS Whacker wrote: > While holding a lecture on PKI today, I was presented with a rather > interesting question that I couldn't answer: > > A company wants to set up a web server that is secured through SSL, > and would like it to have maximum availability to the public out there > while keeping maximum trust within the company. The way they tried to > solve this was to have the server return two server certificates, one > signed by VeriSign, which would be used by "the public out there" and > one that's signed by the internal company CA. > > Of course, this fails, since the server will only use one server > certificate and one private key for it's communication. > > So, my idea was that the company could create a local copy of the > VeriSign CA certificate, but signed by the internal company CA instead > of the next level VeriSign CA. This means that the server certificate > signed by VeriSign could be used, and the certification path would > differ depending on your trust point (inside the company, the trust > point is the internal company CA, outside it would be VeriSign). In > that copy of VeriSign CA cert, one could add all kinds of constraints > so it could only be used to certify the intended web server's server > certificate. > > However, that idea has a problem: the company in question doesn't > trust VeriSign. Period. This means that it's potentially possible > that someone grabs VeriSigns CA private keys, creates a new server > certificate for the server in question, sets up a different server > that uses this new server certificate and spoofs DNS to get the web > server name redirected to themselves instead of the original machine.
I'd suggest to think about "trust" definition here. In case they dont believe in content of pages coming from web server, one could switch to some signed data type. If they concerned about secrecy of data they send to server, start using encrypted-to-some-private-key data types. Other solutions may better fit their (yet unknown) requirements good luck, Vadim > > So, my solution has flaws... > > The only real solution we found so far was to have the server > available on ports 443 (for the public out there) and 444 (for access > from inside the company), and have those two ports return the > corresponding server certificate (443 would return the certificate > signed by VeriSign, 444 would return the certificate signed by the > internal company CA). > > Any other ideas? Solving this in a better way than having two ports > would be quite welcome. > > -- > Richard Levitte \ Spannv?gen 38, II \ [EMAIL PROTECTED] > Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 > \ SWEDEN \ or +46-708-26 53 44 > Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED] > Member of the OpenSSL development team: http://www.openssl.org/ > > Unsolicited commercial email is subject to an archival fee of $400. > See <http://www.stacken.kth.se/~levitte/mail/> for more info. > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
