RE: OT: Encryption and Credit Card Processing (fwd)

Can others with more incite to verisign certs verify this information for
me? thanks in advance:


In response to your question (see below) about surrogate/gated
functionality built into the major browsers since Netscape and IE version
3, the answer is simple. To address the global needs of the US financial
community, the US Government agreed to this functionality for both domestic
and exportable versions of the browser. The Federal Government agreed to
this provided the server that triggers the higher strength processing is
operating in the US or Canada and a domestic commercial certificate
authority (CA) with the capability of issuing such certificates is
utilized. To my knowledge, only VeriSign can provide such certificates. I
have been involved with the installation of global certificates on
Netscape, iPlanet, and IIS web servers since at least the first quarter of
the Year 2000. Initially, WebLogic servers could not handle global
certificates even though BEA claimed its software did. Once BEA completed
its legal agreement with VeriSign, the issue was supposedly
resolved. While I expect that this is true, I have never validated it for
myself. I don't recall that an Apache web server could handle the Global
certificates. To function properly, the supplier of the web server must
obtain special (export controlled) code from the issuing CA.

Note: I'm note exposing any secrets here. You should be able to obtain
this information freely from the VeriSign, Netscape, and Microsoft public
web sites. You just may have to dig for it awhile.


____________________________________________________________ __________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager majordomo@modssl.org

RE: OT: Encryption and Credit Card Processing (fwd)

Hi there,

On Wed, 29 May 2002, R. DuFresne wrote:

> Can others with more incite to verisign certs verify this information for
> me? thanks in advance:

Dunno about the insightful, but I'll try instead ...

> In response to your question (see below) about surrogate/gated
> functionality built into the major browsers since Netscape and IE version
> 3, the answer is simple. To address the global needs of the US financial
> community, the US Government agreed to this functionality for both domestic
> and exportable versions of the browser. The Federal Government agreed to
> this provided the server that triggers the higher strength processing is
> operating in the US or Canada and a domestic commercial certificate
> authority (CA) with the capability of issuing such certificates is
> utilized. To my knowledge, only VeriSign can provide such certificates. I
> have been involved with the installation of global certificates on
> Netscape, iPlanet, and IIS web servers since at least the first quarter of
> the Year 2000. Initially, WebLogic servers could not handle global
> certificates even though BEA claimed its software did. Once BEA completed
> its legal agreement with VeriSign, the issue was supposedly
> resolved. While I expect that this is true, I have never validated it for
> myself. I don't recall that an Apache web server could handle the Global
> certificates. To function properly, the supplier of the web server must
> obtain special (export controlled) code from the issuing CA.

Apache-based servers can handle this - it requires a sufficient version of
OpenSSL, it has very little to do with apache nor even the ssl module (it
should make no difference between apache-ssl and mod_ssl, for example).
IIRC, configuration is a problem - because these SGC (Server Gated Crypto)
usually consist of a cert chain with an intermediate CA cert that is
unknown to browsers (it is in turn signed by a CA cert that *is* known to
browsers). So, you need to ensure the intermediate cert is also in the
server cert file (or was it the CA list? I forget ...)

One of the problems was that these certificates were being issued with one
or both of a "netscape" cert extension and a "microsoft" cert extension.
If your signed cert didn't contain the microsoft one, then you'd be fine
no matter which version of openssl you were running - in short, without
the microsoft extension present in the cert, even IE browsers would obey
the SSL protocol. With the microsoft extension present however, IE would
enter some deranged brain-state in which it thought it could simply make
up it's own new twist on the SSL protocol. This confused various servers
except IIS until everyone figured out what was going on with Microsoft's
creative side and developed workarounds for it - hence the point about
having a "sufficient" version of OpenSSL. All recent releases of OpenSSL
are OK and can cope with these brain-damaged SSL renegotiate hacks from
IE.

Whether you get a microsoft extension in your SGC cert or not probably
depends on the competency, care, and mood of Verisign - and as with all
things involving either microsoft and/or verisign, you probably need an
agreeable alignment of the planets too. IIRC, people running apache based
servers were being issued with SGC certs some of which contained the
microsoft extension and some of which didn't. Also, the intermediate
signing certificate varied quite frequently, so it wasn't possible to
hard-code a fixed set of intermediate certs as "trusted" - it was usually
necessary to treat the intermediate cert as part of the server-cert-chain.

But this is all rather moot, see below ...

> Note: I'm note exposing any secrets here. You should be able to obtain
> this information freely from the VeriSign, Netscape, and Microsoft public
> web sites. You just may have to dig for it awhile.

SGC certs are no longer required. It was only ever an issue for
export-crippled browsers anyway and those simply don't (or shouldn't)
exist any more. SGC also cost heaps more. Get a "normal" cert.

Cheers,
Geoff

--
Geoff Thorpe, geoff(at)geoffthorpe(dot)net

2000 years on, it's a different empire but the same
zealots and the same attrocities.


____________________________________________________________ __________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager majordomo@modssl.org