nsSGC,msSGC in whole cert chain?
HI! I have a question about issuing SSL server certs for SGC (step-up certs): Ralf Engelschall's presentation states that extendedKeyUsage = msSGC,nsSGC has to be set in the whole certificate chain. (see http://www.modssl.org/docs/apachecon2001/slide-010-n.html) Now I wonder if this is also required for the root CA cert. Examining Verisign's certificate chain for a "Global Server ID" (step-up certificate) reveals that an intermediate CA cert is used which has extendedKeyUsage set with (2 16 840 1 113733 1 8 1) and (2 16 840 1 113730 4 1). (Found on http://www.verisign.com/support/tlc/class3_install_docs/intermediate/v00g.html) But the issuing root CA cert OU=Class 3 Public Primary Certification Authority O=VeriSign,Inc. C=US seems to be a X.509v1 cert without any extensions (if I looked it up correctly in Mozilla 0.9.2). Any clue? Ciao, Michael. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Compression in SSL
Lutz Jaenicke wrote: > > On Wed, Jul 18, 2001 at 12:06:48PM +0100, Darko Krizic wrote: > > I heard that some versions of SSL offer some kind of compression. > > The RFC for TLS does not define a specific method of compression. > mod_ssl uses the OpenSSL library, that does not provide compression. > (It may in the future.) When serving HTTP over SSL it might be a better approach to learn about compression of the HTTP body instead of messing around with compression on SSL level (see RFC2616, HTTP_ACCEPT_ENCODING env var., HTTP header line "Content-Encoding: gzip"). Ciao, Michael. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: hostname and cert common name different?
Ronald Ruzicka wrote: > > where I simply want a secure connection - I think we will end up in a > philosophical discussion ... ;) No proper authorization without proper authentication. Period. Ciao, Michael. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Intermittent "Page cannot be displayed" and "Cannot find error or DNS error" using mod_ssl and IE 5.5
JT wrote: > > Netscape has a fairly bothersome cache which poses a serious problem when > diagnosing these types of problems. IE on the otherhand has probably the > best cache system for a browser that there is (Although I won't say much > for > there browser itself) but anyways you need to set Netscape up not to use > caches period and then every other try delete the entire cache it uses and > I bet you'll find the same error. Did you *read* the original message before spreading this fud? - Original Message - From: "Kuczborski, Carol L" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, August 06, 2001 10:53 AM Subject: Intermittent "Page cannot be displayed" and "Cannot find error or DNS error" using mod_ssl and IE 5.5 [..] Everything works fine using the Netscape 4.75 browser, we never et the error. [..] Ciao, Michael. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Extracting SSL_CLIENT_S_DN_UID does not work
HI! (Re-sent since my message through gmane didn't come through.) Maybe I'm overlooking the obvious but it seems that env var SSL_CLIENT_S_DN_UID is not set when using a client cert for authentication. The following env vars displayed in my SSI HTML text are relevant here (obfuscated to protect privacy): SSL_CLIENT_S_DN: /O=Company Name/OU=Authc/UID=userid/CN=Full name SSL_CLIENT_S_DN_UID: (none) Is it caused by UID not being the leaf RDN? Ciao, Michael. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED]
Re: Extracting SSL_CLIENT_S_DN_UID does not work
Joe,
many thanks for your response.
Joe Orton wrote:
On Mon, May 19, 2008 at 10:13:45AM +0200, Michael Ströder wrote:
Maybe I'm overlooking the obvious but it seems that env var
SSL_CLIENT_S_DN_UID is not set when using a client cert for authentication.
The following env vars displayed in my SSI HTML text are relevant here
(obfuscated to protect privacy):
SSL_CLIENT_S_DN: /O=Company Name/OU=Authc/UID=userid/CN=Full name
SSL_CLIENT_S_DN_UID: (none)
Is it caused by UID not being the leaf RDN?
That shouldn't make any difference.
Ok, fine.
What versions of OpenSSL and httpd/mod_ssl are you using?
Actually pre-built RPMs shipped with openSUSE 10.3:
# rpm -q openssl apache2
openssl-0.9.8e-45.5
apache2-2.2.4-70.4
Not sure whether these RPMs are based on sources patched by openSUSE.
The "UID" DN tag is ambiguous and probably
maps to something other than what your subject DN uses.
In the current 2.x mod_ssl sources, UID maps to:
#ifdef NID_x500UniqueIdentifier /* new name as of Openssl 0.9.7 */
{ "UID", NID_x500UniqueIdentifier },
#else /* old name, OpenSSL < 0.9.7 */
{ "UID", NID_uniqueIdentifier },
#endif
Hmm, the user ID is already stored by mod_ssl with attribute name "UID"
in env var SSL_CLIENT_S_DN. Given that it's OpenSSL 0.9.8 and that the
attribute type seems to be interpreted as UID is it safe to assume that
the cert contains the right OID?
If NID_x500UniqueIdentifier maps to OID 2.5.4.45 it's plain wrong anyway...
Ciao, Michael.
__
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager[EMAIL PROTECTED]
Re: Extracting SSL_CLIENT_S_DN_UID does not work
Joe Orton wrote: On Fri, May 23, 2008 at 04:46:48PM +0200, Michael Ströder wrote: Hmm, the user ID is already stored by mod_ssl with attribute name "UID" in env var SSL_CLIENT_S_DN. Given that it's OpenSSL 0.9.8 and that the attribute type seems to be interpreted as UID is it safe to assume that the cert contains the right OID? No, unfortunately there is disparity between mod_ssl and OpenSSL here. (I don't know why; I think historically the short name mappings were not unique in OpenSSL possibly, something like that) Hmmpf! So the string representation of SSL_CLIENT_S_DN is completely generated by OpenSSL whereas the single attribute types are generated by mod_ssl by looking at the cert's OID? If NID_x500UniqueIdentifier maps to OID 2.5.4.45 it's plain wrong anyway... It does indeed map to that OID... wrong in what sense? Because the syntax assigned to attribute type 'x500UniqueIdentifier' (OID 2.5.4.45) is 'Bit String' (OID 1.3.6.1.4.1.1466.115.121.1.6) which cannot be used to store a user ID with characters like 'ABCDEF'. http://www.alvestrand.no/objectid/2.5.4.45.html Ciao, Michael. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED]
Re: Extracting SSL_CLIENT_S_DN_UID does not work
Joe Orton wrote:
On Fri, May 23, 2008 at 04:46:48PM +0200, Michael Ströder wrote:
In the current 2.x mod_ssl sources, UID maps to:
#ifdef NID_x500UniqueIdentifier /* new name as of Openssl 0.9.7 */
{ "UID", NID_x500UniqueIdentifier },
#else /* old name, OpenSSL < 0.9.7 */
{ "UID", NID_uniqueIdentifier },
#endif
Hmm, the user ID is already stored by mod_ssl with attribute name "UID" in
env var SSL_CLIENT_S_DN. Given that it's OpenSSL 0.9.8 and that the
attribute type seems to be interpreted as UID is it safe to assume that the
cert contains the right OID?
No, unfortunately there is disparity between mod_ssl and OpenSSL here.
(I don't know why; I think historically the short name mappings were not
unique in OpenSSL possibly, something like that)
OpenSSL uses "UID" for NID_userId (OID mapping an exercise for the
reader, see obj_mac.h in OpenSSL ;). So in fact that's the tag used for
that RDN.
Ok, then the OID in my cert is 0.9.2342.19200300.100.1.1 (attribute type
'uid' specified for pilotPerson). That seems right to me since it's
compliant with RFC 4514 which contains a table of short and long
attribute type names and their OIDs (end of chapter 3).
But now I don't understand the #ifdef-statement mentioned above. From my
understanding it MUST NOT reference NID_x500UniqueIdentifier. It MUST
reference NID_userId. To me that looks clearly like a bug in mod_ssl.
Ciao, Michael.
__
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager[EMAIL PROTECTED]
Re: Extracting SSL_CLIENT_S_DN_UID does not work
Joe Orton wrote: On Fri, May 23, 2008 at 05:23:34PM +0200, Michael Ströder wrote: Ok, then the OID in my cert is 0.9.2342.19200300.100.1.1 (attribute type 'uid' specified for pilotPerson). That seems right to me since it's compliant with RFC 4514 which contains a table of short and long attribute type names and their OIDs (end of chapter 3). But now I don't understand the #ifdef-statement mentioned above. From my understanding it MUST NOT reference NID_x500UniqueIdentifier. It MUST reference NID_userId. To me that looks clearly like a bug in mod_ssl. Changing it would break backwards-compat which is why the #ifdef is there (so that the _UID variable refers to the same OID regardless of what OpenSSL version si use). 1. I seriously doubt that there are any certs out there which use x500UniqueIdentifier in the subject-DN. If yes, then these certs are also seriously broken. 2. It's simply broken that attribute type UID in mod_ssl differs from OpenSSL here. Ciao, Michael. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED]
Re: Extracting SSL_CLIENT_S_DN_UID does not work
Michael Ströder wrote: Joe Orton wrote: On Fri, May 23, 2008 at 05:23:34PM +0200, Michael Ströder wrote: Ok, then the OID in my cert is 0.9.2342.19200300.100.1.1 (attribute type 'uid' specified for pilotPerson). That seems right to me since it's compliant with RFC 4514 which contains a table of short and long attribute type names and their OIDs (end of chapter 3). But now I don't understand the #ifdef-statement mentioned above. From my understanding it MUST NOT reference NID_x500UniqueIdentifier. It MUST reference NID_userId. To me that looks clearly like a bug in mod_ssl. Changing it would break backwards-compat which is why the #ifdef is there (so that the _UID variable refers to the same OID regardless of what OpenSSL version si use). To come around this: How about letting the deployer specify the OIDs in httpd.conf? Backwards-compability could be achieved with this. Ciao, Michael. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED]
Re: Extracting SSL_CLIENT_S_DN_UID does not work
Michael Ströder wrote: Joe Orton wrote: On Fri, May 23, 2008 at 05:23:34PM +0200, Michael Ströder wrote: Ok, then the OID in my cert is 0.9.2342.19200300.100.1.1 (attribute type 'uid' specified for pilotPerson). That seems right to me since it's compliant with RFC 4514 which contains a table of short and long attribute type names and their OIDs (end of chapter 3). But now I don't understand the #ifdef-statement mentioned above. From my understanding it MUST NOT reference NID_x500UniqueIdentifier. It MUST reference NID_userId. To me that looks clearly like a bug in mod_ssl. Changing it would break backwards-compat which is why the #ifdef is there (so that the _UID variable refers to the same OID regardless of what OpenSSL version si use). 1. I seriously doubt that there are any certs out there which use x500UniqueIdentifier in the subject-DN. If yes, then these certs are also seriously broken. 2. It's simply broken that attribute type UID in mod_ssl differs from OpenSSL here. Please take note of this Apache issue and consider the patch attached: https://issues.apache.org/bugzilla/show_bug.cgi?id=45107 Ciao, Michael. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED]
Re: Generic question on CRL use
Gilles Cuesta wrote: So, at a time, we have 2 ClientCA with different key and different validity period, but same DN. This is bad practice. Try searching for "CA key roll-over". The problem is, when verifying client cert work with both ClientCA stacked; but when using CRL, old clients work only if CRL is signed by old ClientCA. Well, you asked for trouble... You could try to add the authorityKeyIdentifier extension to the CRL if it's also present in the CA certs. This could work with some software. But my strong recommendation: Fix your 2nd ClientCA cert. Ciao, Michael. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED]
Re: Generic question on CRL use
Gilles Cuesta wrote: 2008/6/16 Michael Ströder <[EMAIL PROTECTED]>: Gilles Cuesta wrote: So, at a time, we have 2 ClientCA with different key and different validity period, but same DN. This is bad practice. Try searching for "CA key roll-over". I found docs about it, but proprietary PKI, and couldn't know if this feature is implemented ... It's not a "feature"! Pretty sure there are docs out there describing best practices when conducting a CA key roll-over. One of the best practices is to change the subject DN of the CA entity cert. You could try to add the authorityKeyIdentifier extension to the CRL if it's also present in the CA certs. This could work with some software. X509v3 Authority Key Identifier: keyid:56:4D:A9... But it doesn't work asis, issuing "signature verification error" in apache error logs ... Glad you learned so soon that it's better to rework your re-newed sub-CA cert. ;-) Ciao, Michael. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED]
Re: Apache removal of user's access rights
Beth E. Okun wrote: We're running Apache with ssl enabled..We're using Basic authentication, and if the user browses away from our site and then comes back, they are not forced to log on again...it appears that these settings are being stored somewhere, or that the connection is not being closed.. How about to read about how Basic Authentication works? Or maybe watch the traffic with http://livehttpheaders.mozdev.org? Basically the browser caches username/password once entered for a HTTP authc realm and sends it in the header of every HTTP request. That's the problem with HTTP basic authc. Ciao, Michael. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED]
Re: X509 variables ..UID
Peter Sylvester wrote: > in ssl_engine_vars, there seems to be a problem to me concerning the UID > field. > The syntax for the field is a bitstring and not a "text". Nothing happened since I've filed this bug and raised the issue here: https://issues.apache.org/bugzilla/show_bug.cgi?id=45107 It's broken => it should be fixed. Unfortunately no-one cares. :-( Ciao, Michael. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED]
SSL_SESSION_ID on RHEL 5.5
HI! For security reasons I'm using env var SSL_SESSION_ID to cross-check the application's session ID with the SSL session ID in my web application. This works without any issues on my openSUSE boxes. Browser is Seamonkey 2.0.4. But I have problems with Apache 2.2.3 shipped with Red Hat Enterprise Linux Server release 5.5 (Tikanga) Cery soon the SSL session seems to be renegotiated resulting in a new value in SSL_SESSION_ID Relevant settings for SSL session resumptions: SSLSessionCache shmcb:/var/cache/mod_ssl/scache(512000) SSLSessionCacheTimeout 7200 Any hint? Were there relevant fixes to mod_ssl after release 2.2.3? Or maybe Red Hat backported patches against renegotiation attacks which cause the issue? Ciao, Michael. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Managermajord...@modssl.org
