Re: Security Vulnerability issue in openssl 9.8 version
Customer are started asking me for this fix . So i need to release an immediate release of openssl with this fix . Not sure whether they are using DTLS . If any customer ask for the fix , i need to release the fix immediately (business policy). The patch which i have applied is this(for openssl 9.8h and openssl 98k ) http://cvs.openssl.org/chngview?cn=18187 http://cvs.openssl.org/chngview?cn=18206 http://cvs.openssl.org/chngview?cn=18154 This is patch correct ? And is the openssl community going to announce this security vulnerability issue ? Please help Thanks Rajan On Wed, Jun 3, 2009 at 5:44 AM, Victor Duchovni < victor.ducho...@morganstanley.com> wrote: > On Tue, Jun 02, 2009 at 12:33:46AM -0700, rajanchittil wrote: > > > > > Hi All, > > > > Recently i got a security vulnerability issue alert reported in > > http://www.vupen.com/english/advisories/2009/1377. > > Are you using DTLS? If you application is not using DTLS (very few are), > you don't need to patch anything. DTLS support in OpenSSL does not > appear to be very mature at this time, and I don't expect that very > many users are impacted by this issue. > > -- >Viktor. > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
Re: What type of DES is DES_ecb_encrypt?
DES_ecb_encrypt encrypts as single DES, 56-bit key, in a block mode which has been deemed completely insecure. -Kyle H On Wed, Jun 3, 2009 at 12:46 PM, Michael Kurecka wrote: > Does the method DES_ecb_encrypt encrypt as Triple or Single DES __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Callback suggestion for unsupported cert extensions
There are also strict rules regarding the certificate validation process, which openssl will let you entirely "pre-empt" and completely take over the validation process. All we would be asking for would be a callback that lets us "extend" the functionality of openssl regarding cert extensions. In your case, because you need to stick with "unmodified" openssl code, using a command-line operation, this may not help you as much. Randy On Jun 3, 2009, at 11:00 PM, Brad Mitchell wrote: The thing is, RFC3280 states... Implementors are warned that the X.500 standards community has developed a series of extensibility rules. These rules determine when an ASN.1 definition can be changed without assigning a new object identifier (OID). For example, at least two extension definitions included in RFC 2459 [RFC 2459], the predecessor to this profile document, have different ASN.1 definitions in this specification, but the same OID is used. If unknown elements appear within an extension, and the extension is not marked critical, those unknown elements ought to be ignored, as follows: (a) ignore all unknown bit name assignments within a bit string; (b) ignore all unknown named numbers in an ENUMERATED type or INTEGER type that is being used in the enumerated style, provided the number occurs as an optional element of a SET or SEQUENCE; and (c) ignore all unknown elements in SETs, at the end of SEQUENCEs, or in CHOICEs where the CHOICE is itself an optional element of a SET or SEQUENCE. If an extension containing unexpected values is marked critical, the implementation MUST reject the certificate or CRL containing the unrecognized extension. ^^ This pretty much means if there is an unexpected value and it is critical then it has to be rejected. I'm not sure how Microsoft would like their "private" extensions being listed in openssl. You would think from a standards compliance POV they would welcome it but who knows. Brad -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Randy Turner Sent: Thursday, 4 June 2009 3:48 PM To: openssl-users@openssl.org Subject: Re: Callback suggestion for unsupported cert extensions I agree that there should probably be a callback for extensions not recognized and supported by OpenSSL...the callback could return a failure code that openssl would look at, and if it is set to an "error" then openssl would run it's normal failure return path (up the call stack). If the callback returns SUCCESS, then keep going... If a plugin is not registered for handling unknown extensions, then maybe the code should follow a configuration flag that says ["fail" on unknown extension] or [ignore unknown extensions] Randy On Jun 3, 2009, at 10:41 PM, Victor B. Wagner wrote: On 2009.06.04 at 09:04:11 +1000, Brad Mitchell wrote: The reason we use command-line utilities to verify is for transparency. Data could be used in the courts for example and having that "hey.. go download openssl and verify it yourself" is a lot better than.. here is a util we wrote to verify the token. WHAT? Your util? sure. So the issue with ignoring those extensions within your own app will probably work for you depending on your situation. In my case, it is not really an option. I'm not really sure why this particular extension is marked as critical. It does seem a bit weird. Microsoft aren't exactly the most compliant company out there when it comes to some industry standards... Hm, description of the X509_F_FLAG_INGORE_CRITICAL reads "Ignore UNKNOWN critical extensions". May be it is better to make these Microsoft-specific extension KNOWN to OpenSSL, even it wouldn't do anything with their values. Just "a thing which MS-CA can put into certificate, and mark critical, which doesn't affect verification process". It is quite easy to do: just add OID of this extension into objects.txt with suitable shortname and longname, and add it into array in the X509_supported_extension function. Really I think it might be worth effort to make list of supported-extensions user-configurable. Applications can handle extensions, which are not supported by OpenSSL itself using verify callback function. __ OpenSSL Project http:// www.openssl.org User Support Mailing Listopenssl- us...@openssl.org Automated List Manager majord...@openssl.org No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.339 / Virus Database: 270.12.51/2151 - Release Date: 06/03/09 18:00:00 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org A
RE: Callback suggestion for unsupported cert extensions
The thing is, RFC3280 states... Implementors are warned that the X.500 standards community has developed a series of extensibility rules. These rules determine when an ASN.1 definition can be changed without assigning a new object identifier (OID). For example, at least two extension definitions included in RFC 2459 [RFC 2459], the predecessor to this profile document, have different ASN.1 definitions in this specification, but the same OID is used. If unknown elements appear within an extension, and the extension is not marked critical, those unknown elements ought to be ignored, as follows: (a) ignore all unknown bit name assignments within a bit string; (b) ignore all unknown named numbers in an ENUMERATED type or INTEGER type that is being used in the enumerated style, provided the number occurs as an optional element of a SET or SEQUENCE; and (c) ignore all unknown elements in SETs, at the end of SEQUENCEs, or in CHOICEs where the CHOICE is itself an optional element of a SET or SEQUENCE. If an extension containing unexpected values is marked critical, the implementation MUST reject the certificate or CRL containing the unrecognized extension. ^^ This pretty much means if there is an unexpected value and it is critical then it has to be rejected. I'm not sure how Microsoft would like their "private" extensions being listed in openssl. You would think from a standards compliance POV they would welcome it but who knows. Brad -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Randy Turner Sent: Thursday, 4 June 2009 3:48 PM To: openssl-users@openssl.org Subject: Re: Callback suggestion for unsupported cert extensions I agree that there should probably be a callback for extensions not recognized and supported by OpenSSL...the callback could return a failure code that openssl would look at, and if it is set to an "error" then openssl would run it's normal failure return path (up the call stack). If the callback returns SUCCESS, then keep going... If a plugin is not registered for handling unknown extensions, then maybe the code should follow a configuration flag that says ["fail" on unknown extension] or [ignore unknown extensions] Randy On Jun 3, 2009, at 10:41 PM, Victor B. Wagner wrote: > On 2009.06.04 at 09:04:11 +1000, Brad Mitchell wrote: > >> >> The reason we use command-line utilities to verify is for >> transparency. >> Data could be used in the courts for example and having that "hey.. >> go >> download openssl and verify it yourself" is a lot better than.. >> here is a >> util we wrote to verify the token. WHAT? Your util? sure. >> >> So the issue with ignoring those extensions within your own app will >> probably work for you depending on your situation. In my case, it >> is not >> really an option. >> >> I'm not really sure why this particular extension is marked as >> critical. It >> does seem a bit weird. Microsoft aren't exactly the most compliant >> company >> out there when it comes to some industry standards... > > Hm, description of the X509_F_FLAG_INGORE_CRITICAL reads "Ignore > UNKNOWN > critical extensions". May be it is better to make these > Microsoft-specific extension KNOWN to OpenSSL, even it wouldn't do > anything with their values. > > Just "a thing which MS-CA can put into certificate, and mark critical, > which doesn't affect verification process". > > It is quite easy to do: > > just add OID of this extension into objects.txt with suitable > shortname > and longname, and add it into array in the X509_supported_extension > function. > > Really I think it might be worth effort to make list of > supported-extensions user-configurable. Applications can handle > extensions, which are not supported by OpenSSL itself using verify > callback function. > > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org > No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.339 / Virus Database: 270.12.51/2151 - Release Date: 06/03/09 18:00:00 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Callback suggestion for unsupported cert extensions
I agree that there should probably be a callback for extensions not recognized and supported by OpenSSL...the callback could return a failure code that openssl would look at, and if it is set to an "error" then openssl would run it's normal failure return path (up the call stack). If the callback returns SUCCESS, then keep going... If a plugin is not registered for handling unknown extensions, then maybe the code should follow a configuration flag that says ["fail" on unknown extension] or [ignore unknown extensions] Randy On Jun 3, 2009, at 10:41 PM, Victor B. Wagner wrote: On 2009.06.04 at 09:04:11 +1000, Brad Mitchell wrote: The reason we use command-line utilities to verify is for transparency. Data could be used in the courts for example and having that "hey.. go download openssl and verify it yourself" is a lot better than.. here is a util we wrote to verify the token. WHAT? Your util? sure. So the issue with ignoring those extensions within your own app will probably work for you depending on your situation. In my case, it is not really an option. I'm not really sure why this particular extension is marked as critical. It does seem a bit weird. Microsoft aren't exactly the most compliant company out there when it comes to some industry standards... Hm, description of the X509_F_FLAG_INGORE_CRITICAL reads "Ignore UNKNOWN critical extensions". May be it is better to make these Microsoft-specific extension KNOWN to OpenSSL, even it wouldn't do anything with their values. Just "a thing which MS-CA can put into certificate, and mark critical, which doesn't affect verification process". It is quite easy to do: just add OID of this extension into objects.txt with suitable shortname and longname, and add it into array in the X509_supported_extension function. Really I think it might be worth effort to make list of supported-extensions user-configurable. Applications can handle extensions, which are not supported by OpenSSL itself using verify callback function. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org smime.p7s Description: S/MIME cryptographic signature
Re: RE: Problems verifying certificates generated by Microsoft Certificate Authority and timestamping
On 2009.06.04 at 09:04:11 +1000, Brad Mitchell wrote: > > The reason we use command-line utilities to verify is for transparency. > Data could be used in the courts for example and having that "hey.. go > download openssl and verify it yourself" is a lot better than.. here is a > util we wrote to verify the token. WHAT? Your util? sure. > > So the issue with ignoring those extensions within your own app will > probably work for you depending on your situation. In my case, it is not > really an option. > > I'm not really sure why this particular extension is marked as critical. It > does seem a bit weird. Microsoft aren't exactly the most compliant company > out there when it comes to some industry standards... Hm, description of the X509_F_FLAG_INGORE_CRITICAL reads "Ignore UNKNOWN critical extensions". May be it is better to make these Microsoft-specific extension KNOWN to OpenSSL, even it wouldn't do anything with their values. Just "a thing which MS-CA can put into certificate, and mark critical, which doesn't affect verification process". It is quite easy to do: just add OID of this extension into objects.txt with suitable shortname and longname, and add it into array in the X509_supported_extension function. Really I think it might be worth effort to make list of supported-extensions user-configurable. Applications can handle extensions, which are not supported by OpenSSL itself using verify callback function. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Re: Re: about ec_point and ec_group
On 2009.06.04 at 08:13:05 +0800, jazeltq wrote: > >I'm afraid that it is not a good code to study ecc. > > > >Implementation, which is currently in OpenSSL is full of obscure > >performance hacks and is not well-documented. > Yse, it's a problem . May be it will be relief afer my paper finished. It would be nice, because this ecc library is fast. I have compared its speed with some proprietary implementations of EC-based signature algorithms, and it outperforms them. Moreover, may be even some of performance hacks worth documenting as good way to improve speed of EC operations. > >When I've used it to implement GOST R 34.10-2001 algorithm in the ccgost > >engine, it took some pain to understand even knowing the math and having > >standard text handy. > gost ? It is the Russia digital signature standard, is't it? > oh, i see "cryptocom.ru" , are you come from Russia ? I've not come anywhere. I'm just sitting in my office in Moscow. ;-) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Problems verifying certificates generated by Microsoft Certificate Authority and timestamping
The ts command is to create requests, sign requests and verify timestamps according to RFC3161. So the exercise I was trying to demonstrate at work was to create a certificate for the purpose of timeStamping (critical extension timeStamping on the cert) to sign digests into a token. The verify function was just to demonstrate that the part of the process that was failing (verifying the token) was actually verifying the certificate. It had not even gotten to the stage where it would verify the token. The reason we use command-line utilities to verify is for transparency. Data could be used in the courts for example and having that "hey.. go download openssl and verify it yourself" is a lot better than.. here is a util we wrote to verify the token. WHAT? Your util? sure. So the issue with ignoring those extensions within your own app will probably work for you depending on your situation. In my case, it is not really an option. I'm not really sure why this particular extension is marked as critical. It does seem a bit weird. Microsoft aren't exactly the most compliant company out there when it comes to some industry standards... Brad -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Randy Turner Sent: Thursday, 4 June 2009 1:07 AM To: openssl-users@openssl.org Subject: Re: Problems verifying certificates generated by Microsoft Certificate Authority and timestamping Hi Brad, I guess I'm going to have the same problem (Microsoft CA generating certs I have to verify with OpenSSL). I wasn't aware of the "ts" command, but I'm assuming that I can always verify MS-CA certificates if I do this programatically, using the openssl api. I will have to verify timestamp as well as other general identity certs, but I will always do this from custom software using the openssl API, and not using interactive command line utiliities. If there are any issues ignoring critical extensions programatically, then please let me know. I'm not sure why Microsoft is marking these extensions as critical. Randy On Jun 3, 2009, at 12:35 AM, Brad Mitchell wrote: > > For anyone that cares. > > > > I ran: > > > > certutil -showreg policy > > > > which gave me the registry entry for cert policies: > > > > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc > \Configuration\LUCINDA ROOT CA\PolicyModules > \CertificateAuthority_MicrosoftDefault.Policy > > > > I modified the multi-string value: DisableExtensionList > > And added: > > > > 1.3.6.1.4.1.311.21.10 > > > > MS CA no longer adds this extension to certificates it produces. > I'm not sure what the long term affects of this would be in an > enterprise but this is what I've done to remove it. > > > > brad > > From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org > ] On Behalf Of Brad Mitchell > Sent: Wednesday, 3 June 2009 11:15 AM > To: openssl-users@openssl.org > Subject: Re: Problems verifying certificates generated by Microsoft > Certificate Authority and timestamping > > > > Hi, > > > > I've been trying to get Time Stamping working where the CA issuing > the Time Stamping certificate is issued by a Microsoft Windows > Server 2003 Enterprise CA. > > > > I've had success in terms of being able to actually sign the digest > and I actually have a certificate with the purpose of Time Stamp > Signing as YES. > > > > I am however having issues when I try to verify a token against the > certificate. > > > > error 34 at 0 depth lookup:unhandled critical extension > > > > This also happens when: > > > > openssl verify -Cafile ca.cer tsatest.cer > > > > tsatest.cer: /C=AU/ST=NSW/L=Sydney/O=Test TSA/OU=TSA/CN=Mr Test/ > emailAddress=tes > > t...@test.com.au > > error 34 at 0 depth lookup:unhandled critical extension > > OK > > > > Sure I can get this to ignore the critical extension: > > > > openssl verify -ignore_critical -CAfile ca.cer tsatest.cer > > tsatest.cer: OK > > > > There is no way however to do this using the "ts" commands for > verifying RFC3161 tokens/responses. > > > > Whilst I could modify the ts.c and set the ignore_critical flag in > the X509 STORE, according to RFC3280. > > Line from the verify help page for openssl: > > > > "Normally if an unhandled critical extension is present which is not > supported by OpenSSL the certificate is rejected (as required by > RFC3280 et al). If this option is set critical extensions are > ignored." > > > > I'm guessing this has something to do with these stupid application > extensions it has put on the certificate when generated from the > Microsoft CA: > > > > > > X509v3 Basic Constraints: critical > > CA:FALSE > > X509v3 Key Usage: > > Digital Signature, Non Repudiation > > 1.3.6.1.4.1.311.21.7: > > 0..&+.7.Y../...z.=...z...@..d... > > X509v3 Extended K
Re:Re: Re: about ec_point and ec_group
在2009-06-03，"Victor B. Wagner" 写道： >On 2009.06.03 at 08:23:52 +0800, jazeltq wrote: > >> >file ec_lcl.h, which present in the OpenSSL sources, but not included in >> which directory include file ec_lcl.h, is it in the ec directory ?but in >> my sources i can't find it. > >It is in crypto/ec. > >Which version of OpenSSL are you using? In both 0.9.8 and 1.0.0-beta it >is here. yes,it is there, just because i put ec_lcl.h in the /usr/include directory some day ago. thank you ! > >> I just want to study the ecc, and want to know it deeply, > >I'm afraid that it is not a good code to study ecc. > >Implementation, which is currently in OpenSSL is full of obscure >performance hacks and is not well-documented. Yse, it's a problem . May be it will be relief afer my paper finished. > >When I've used it to implement GOST R 34.10-2001 algorithm in the ccgost >engine, it took some pain to understand even knowing the math and having >standard text handy. gost ? It is the Russia digital signature standard, is't it? oh, i see "cryptocom.ru" , are you come from Russia ? > >__ >OpenSSL Project http://www.openssl.org >User Support Mailing Listopenssl-users@openssl.org >Automated List Manager majord...@openssl.org
Re: TLS compatibility problem -- can connect to server with NSS but not OpenSSL.
On Wed, Jun 03, 2009 at 10:24:47PM +0100, David Woodhouse wrote: > On Wed, 2009-06-03 at 15:02 -0400, Victor Duchovni wrote: > > with SSL_CTX_use_certificate_chain_file() the entire trust chain is > > loaded from the provided file bottom-up order. The first certificate > > is the leaf and must match the private key provided. > > Ah, right. Most files I've encountered have had only the _one_ > certificate. The code path you describe seems to be labelled with > /* A Thawte special :-) */ Perhaps Thawte were the first to mass-market leaf certs signed by intermediate CAs, making the need for additional certs to be included in the trust chain beyond the leaf cert. > throughout the addition and usage of those extra certs -- is that really > the way it's _supposed_ to be done? The SSL_CTX_use_certificate_chain_file() API is a very admin friendly way to support installation of cert + chain and even key + cert + chain, as the key can also be stored in the same file (ideally mode 0600 or passphrase-protected). -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS compatibility problem -- can connect to server with NSS but not OpenSSL.
On Wed, 2009-06-03 at 15:02 -0400, Victor Duchovni wrote: > with SSL_CTX_use_certificate_chain_file() the entire trust chain is > loaded from the provided file bottom-up order. The first certificate > is the leaf and must match the private key provided. Ah, right. Most files I've encountered have had only the _one_ certificate. The code path you describe seems to be labelled with /* A Thawte special :-) */ throughout the addition and usage of those extra certs -- is that really the way it's _supposed_ to be done? -- dwmw2 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Regarding the corresponding remove functions
We are currently using OpenSSL 0.9.8j and have a question related to X509_LOOKUP_ctrl and X509_LOOKUP_load_file. Basically, we are using one of the above functions to add the files to the LOOKUP, however, under some conditions, it is required to remove the file. Would there be any document or function description mentions this with any implications? Also, going ahead and deleting the whole LOOKUP is no preferred. Thanks, Tushar
What type of DES is DES_ecb_encrypt?
Does the method DES_ecb_encrypt encrypt as Triple or Single DES
Re: TLS compatibility problem -- can connect to server with NSS but not OpenSSL.
On Wed, Jun 03, 2009 at 07:27:00PM +0100, David Woodhouse wrote:
> On Tue, 2009-06-02 at 21:39 -0400, Victor Duchovni wrote:
> > The CAfile is for verification, not for sending alon the trust chain
> > of a given certificate.
>
> OpenSSL currently _does_ use the CAfile for sending along the trust
> chain of its client certificate. It's buggy, but it tries :)
>
> > DO NOT append your CAfile to your certificate, instead include just
> > the leaf cert, then the issuing CAs bottom-up in the right order.
>
> AFAICT that doesn't make any difference -- OpenSSL doesn't use them from
> there anyway (unless it's a PKCS#12 file, but the client application has
> to handle all that manually anyway).
For most OpenSSL based applications that use a key+cert own (rather
than just verify remote certs), the private key and own cert are loaded
via code along the lines of (this is from Postfix):
/*
* We need both the private key (in key_file) and the public key
* certificate (in cert_file). Both may specify the same file.
*
* Code adapted from OpenSSL apps/s_cb.c.
*/
ERR_clear_error();
if (SSL_CTX_use_certificate_chain_file(ctx, cert_file) <= 0) {
msg_warn("cannot get %s certificate from file %s: "
"disabling TLS support", cert_type, cert_file);
tls_print_errors();
return (0);
}
if (SSL_CTX_use_PrivateKey_file(ctx, key_file, SSL_FILETYPE_PEM) <= 0) {
msg_warn("cannot get %s private key from file %s: "
"disabling TLS support", cert_type, key_file);
tls_print_errors();
return (0);
}
/*
* Sanity check.
*/
if (!SSL_CTX_check_private_key(ctx)) {
msg_warn("%s private key in %s does not match public key in %s: "
"disabling TLS support", cert_type, key_file, cert_file);
return (0);
}
return (1);
with SSL_CTX_use_certificate_chain_file() the entire trust chain is
loaded from the provided file bottom-up order. The first certificate
is the leaf and must match the private key provided.
If you application is using an interface for loading discrete certificates,
it needs to be configured to load the required certificates one at a time,
or via PKCS#12 if that is what it wants to do. The above code-path is
far simpler.
--
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: TLS compatibility problem -- can connect to server with NSS but not OpenSSL.
On Tue, 2009-06-02 at 21:39 -0400, Victor Duchovni wrote: > The CAfile is for verification, not for sending alon the trust chain > of a given certificate. OpenSSL currently _does_ use the CAfile for sending along the trust chain of its client certificate. It's buggy, but it tries :) > DO NOT append your CAfile to your certificate, instead include just > the leaf cert, then the issuing CAs bottom-up in the right order. AFAICT that doesn't make any difference -- OpenSSL doesn't use them from there anyway (unless it's a PKCS#12 file, but the client application has to handle all that manually anyway). -- dwmw2 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Problems verifying certificates generated by Microsoft Certificate Authority and timestamping
Hi Brad, I guess I'm going to have the same problem (Microsoft CA generating certs I have to verify with OpenSSL). I wasn't aware of the "ts" command, but I'm assuming that I can always verify MS-CA certificates if I do this programatically, using the openssl api. I will have to verify timestamp as well as other general identity certs, but I will always do this from custom software using the openssl API, and not using interactive command line utiliities. If there are any issues ignoring critical extensions programatically, then please let me know. I'm not sure why Microsoft is marking these extensions as critical. Randy On Jun 3, 2009, at 12:35 AM, Brad Mitchell wrote: For anyone that cares. I ran: certutil –showreg policy which gave me the registry entry for cert policies: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc \Configuration\LUCINDA ROOT CA\PolicyModules \CertificateAuthority_MicrosoftDefault.Policy I modified the multi-string value: DisableExtensionList And added: 1.3.6.1.4.1.311.21.10 MS CA no longer adds this extension to certificates it produces. I’m not sure what the long term affects of this would be in an enterprise but this is what I’ve done to remove it. brad From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org ] On Behalf Of Brad Mitchell Sent: Wednesday, 3 June 2009 11:15 AM To: openssl-users@openssl.org Subject: Re: Problems verifying certificates generated by Microsoft Certificate Authority and timestamping Hi, I’ve been trying to get Time Stamping working where the CA issuing the Time Stamping certificate is issued by a Microsoft Windows Server 2003 Enterprise CA. I’ve had success in terms of being able to actually sign the digest and I actually have a certificate with the purpose of Time Stamp Signing as YES. I am however having issues when I try to verify a token against the certificate. error 34 at 0 depth lookup:unhandled critical extension This also happens when: openssl verify –Cafile ca.cer tsatest.cer tsatest.cer: /C=AU/ST=NSW/L=Sydney/O=Test TSA/OU=TSA/CN=Mr Test/ emailAddress=tes t...@test.com.au error 34 at 0 depth lookup:unhandled critical extension OK Sure I can get this to ignore the critical extension: openssl verify -ignore_critical -CAfile ca.cer tsatest.cer tsatest.cer: OK There is no way however to do this using the “ts” commands for verifying RFC3161 tokens/responses. Whilst I could modify the ts.c and set the ignore_critical flag in the X509 STORE, according to RFC3280. Line from the verify help page for openssl: “Normally if an unhandled critical extension is present which is not supported by OpenSSL the certificate is rejected (as required by RFC3280 et al). If this option is set critical extensions are ignored.” I’m guessing this has something to do with these stupid application extensions it has put on the certificate when generated from the Microsoft CA: X509v3 Basic Constraints: critical CA:FALSE X509v3 Key Usage: Digital Signature, Non Repudiation 1.3.6.1.4.1.311.21.7: 0..&+.7.Y../...z.=...z...@..d... X509v3 Extended Key Usage: critical Time Stamping 1.3.6.1.4.1.311.21.10: critical 0.0 Does anyone out there have any experience with generating certificates from Microsoft CA without these unknown extensions? I’m guessing in this case it’s the 1.3.6.1.4.1.311.21.10. Application Policies extension -- same encoding as szOID_CERT_POLICIES szOID_APPLICATION_CERT_POLICIES 1.3.6.1.4.1.311.21.10 ^^ from some Microsoft page. Any ideas?? Thanks, Brad No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.339 / Virus Database: 270.12.46/2142 - Release Date: 06/02/09 17:53:00 smime.p7s Description: S/MIME cryptographic signature
Re: s_client output
Joe Friedeggs writes: > I'm pretty much a noob when it comes to SSL, so any help would be > greatly appreciated. I just installed Openldap running TLS with self > signed certs. Everything *seems* to be working fine (LDAP logs show > TLS encryption), but when I run the s_client from the LDAP (Linux) > client, I only see ONLY: I would guess that your server (and client) are using STARTTLS (so they start in LDAP and use an LDAP protocol command to switch to TLS). s_client (as of 0.9.8something) doesn't know about LDAP STARTTLS (and you didn't specify -starttls anyway). wireshark ought to show you what's happening (presuming you can get that working, of course). [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
s_client output
I'm pretty much a noob when it comes to SSL, so any help would be greatly appreciated. I just installed Openldap running TLS with self signed certs. Everything *seems* to be working fine (LDAP logs show TLS encryption), but when I run the s_client from the LDAP (Linux) client, I only see ONLY: [ops_...@client-12 ~]$ openssl s_client -connect ldapmaster:389 -CAfile /etc/openldap/cacerts/cacert.pem -debug -showcerts -msg CONNECTED(0003) write to 0x898e580 [0x898e5c8] (133 bytes => 133 (0x85)) - 80 83 01 03 01 00 5a 00-00 00 20 00 00 39 00 00 ..Z... ..9.. 0010 - 38 00 00 35 00 00 16 00-00 13 00 00 0a 07 00 c0 8..5 0020 - 00 00 33 00 00 32 00 00-2f 03 00 80 00 00 66 00 ..3..2../.f. 0030 - 00 05 00 00 04 01 00 80-00 00 63 00 00 62 00 00 ..c..b.. 0040 - 15 00 00 12 00 00 09 06-00 40 00 00 65 00 00 64 .@..e..d 0050 - 00 00 14 00 00 11 00 00-08 00 00 06 04 00 80 00 0060 - 00 03 02 00 80 25 69 cc-1f a3 5f ee 06 b4 cd a0 .%i..._. 0070 - 83 c4 b0 38 83 08 80 9f-82 8e fa c5 3c ab 26 79 ...8<.&y 0080 - 8f a8 ee f7 25% >>> SSL 2.0 [length 0083], CLIENT-HELLO 01 03 01 00 5a 00 00 00 20 00 00 39 00 00 38 00 00 35 00 00 16 00 00 13 00 00 0a 07 00 c0 00 00 33 00 00 32 00 00 2f 03 00 80 00 00 66 00 00 05 00 00 04 01 00 80 00 00 63 00 00 62 00 00 15 00 00 12 00 00 09 06 00 40 00 00 65 00 00 64 00 00 14 00 00 11 00 00 08 00 00 06 04 00 80 00 00 03 02 00 80 25 69 cc 1f a3 5f ee 06 b4 cd a0 83 c4 b0 38 83 08 80 9f 82 8e fa c5 3c ab 26 79 8f a8 ee f7 25 Although I've never done this before, I pretty sure I am suppose to see the SERVER-HELLO, followed by the cert, etc. I've tried creating certs various ways (http://www.zytrax.com/tech/survival/ssl.html and http://www.openldap.org/faq/data/cache/185.html), but always get the same results. I am running: RHel5 OpenSSL 0.9.8b openldap-2.3.43 And on the client: [ops_...@client-12 ~]$ openssl x509 -text -in /etc/openldap/cacerts/cacert.pem Certificate: Data: Version: 3 (0x2) Serial Number: 0 (0x0) Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, ST=New York, O=Ima CA, OU=Fingers, CN=Root CA/emailaddress=friedegg...@hotmail.com Validity Not Before: May 28 04:37:13 2009 GMT Not After : May 27 04:37:13 2012 GMT Subject: C=US, ST=New York, O=Ima CA, OU=Fingers, CN=Root CA/emailaddress=friedegg...@hotmail.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:b3:bf:f0:18:5d:7e:57:0a:ce:15:3c:28:2a:81: 6d:e6:c5:31:98:7e:cc:09:03:d2:28:f2:33:3e:88: 11:5f:7d:e1:18:33:35:7d:f5:fa:9d:89:a8:95:16: 08:00:81:08:29:ac:37:b3:b1:2b:f3:20:52:15:d7: 19:44:92:9c:45:e7:2e:58:fe:7e:07:d4:1f:5a:ad: 59:91:37:84:14:a8:4d:df:54:a2:62:66:38:9b:f0: cf:48:01:68:0d:3a:7c:93:83:02:48:e0:76:a1:5c: f9:05:3b:49:1e:03:9a:fd:ea:ee:79:f7:87:66:96: b0:69:79:e1:e6:1a:bd:9e:0d Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 0B:FB:7D:0B:0D:17:A3:CD:79:02:A3:B3:92:57:15:6F:DE:36:07:3C X509v3 Authority Key Identifier: keyid:0B:FB:7D:0B:0D:17:A3:AD:79:02:A3:A3:92:57:15:6F:D1:38:07:3C Signature Algorithm: sha1WithRSAEncryption 28:52:3d:9c:90:e1:89:00:d4:9d:3b:06:a6:32:28:e8:c0:8d: 9d:5a:0b:79:bb:1a:c9:1a:8d:c6:3a:a5:ec:5d:4c:9f:20:4c: c6:1e:41:df:7d:d0:fc:45:09:2b:4b:7c:ff:38:aa:ea:33:a0: 4a:be:7c:84:7c:58:e8:98:7e:c9:0e:4b:5b:11:c6:28:84:b1: 3f:bb:30:03:f6:38:40:9f:2d:32:bc:3a:d7:b8:6f:fd:aa:9f: 67:a6:27:07:53:b2:40:41:86:b7:02:f2:6b:07:6f:1b:74:87: 68:3b:1b:89:13:08:cb:36:f0:3c:3b:5e:d6:df:e3:91:12:86: 7a:e4 -BEGIN CERTIFICATE- MIIDDzCCAnigAwIBAgIBADANBgkqhkiG9w0BAQUFADCBjjELMAkGA1UEBhMCVVMx DjAMBgNVBAgTBVRleGFzMRMwEQYDVQQKEwpCaWd0aW1lIENBMRAwDgYDVQQLEwdT aWduZXJzMRwwGgYDVQQDExNJbnRlZ3JhdGlvbiBSb290IENBMSowKAYJKoZIhvcN AQkBFhtqb2huLmthbmVAcHJvZGVhc3lzdGVtcygjb20wHhcNMDkwNTI4MDQzNzEz WhcNMTIwNTI3MDQzNzEzWjCBjjELMAkGA1UEBhMCVVMxDjAMBgNVBAgTBVRleGFz MRMwEQYDVQQKEwpCaWd0aW1lIENBMRAwDgYDVQQLEwdTaWducXJzMRwwGgYDVQQD ExNJbnRlZ3JhdGlvbiBSb290IENXMSowKAYJKoZIhvcNAQkBFhtqb2huLmthbmVA cHJvZGVhc3lzdGVtcy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALO/ 8BhdflcKzhU8KCqBbebFMZh+zAkD0ijyMz6IEV994RgzNX31+p2JqJUWCACBCCms N7OxK/MgUhXXGUSSerXnLlj+fgfUH1qtWZE3hBSoTd9UomJmOJvwz0gBaA06fJOD AkjgdqFc+QU7SR4Dmv3q7nn3h2aWsGl54eYavZ4NAgMBAAGjezB5MAkGA1UdEwQC MAAwLAYJYIZIAYb4QgENBB8W
Re: Re: about ec_point and ec_group
On 2009.06.03 at 08:23:52 +0800, jazeltq wrote: > >file ec_lcl.h, which present in the OpenSSL sources, but not included in > which directory include file ec_lcl.h, is it in the ec directory ?but in my > sources i can't find it. It is in crypto/ec. Which version of OpenSSL are you using? In both 0.9.8 and 1.0.0-beta it is here. > I just want to study the ecc, and want to know it deeply, I'm afraid that it is not a good code to study ecc. Implementation, which is currently in OpenSSL is full of obscure performance hacks and is not well-documented. When I've used it to implement GOST R 34.10-2001 algorithm in the ccgost engine, it took some pain to understand even knowing the math and having standard text handy. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Problems verifying certificates generated by Microsoft Certificate Authority and timestamping
For anyone that cares. I ran: certutil -showreg policy which gave me the registry entry for cert policies: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\L UCINDA ROOT CA\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy I modified the multi-string value: DisableExtensionList And added: 1.3.6.1.4.1.311.21.10 MS CA no longer adds this extension to certificates it produces. I'm not sure what the long term affects of this would be in an enterprise but this is what I've done to remove it. brad _ From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Brad Mitchell Sent: Wednesday, 3 June 2009 11:15 AM To: openssl-users@openssl.org Subject: Re: Problems verifying certificates generated by Microsoft Certificate Authority and timestamping Hi, I've been trying to get Time Stamping working where the CA issuing the Time Stamping certificate is issued by a Microsoft Windows Server 2003 Enterprise CA. I've had success in terms of being able to actually sign the digest and I actually have a certificate with the purpose of Time Stamp Signing as YES. I am however having issues when I try to verify a token against the certificate. error 34 at 0 depth lookup:unhandled critical extension This also happens when: openssl verify -Cafile ca.cer tsatest.cer tsatest.cer: /C=AU/ST=NSW/L=Sydney/O=Test TSA/OU=TSA/CN=Mr Test/emailAddress=tes t...@test.com.au error 34 at 0 depth lookup:unhandled critical extension OK Sure I can get this to ignore the critical extension: openssl verify -ignore_critical -CAfile ca.cer tsatest.cer tsatest.cer: OK There is no way however to do this using the "ts" commands for verifying RFC3161 tokens/responses. Whilst I could modify the ts.c and set the ignore_critical flag in the X509 STORE, according to RFC3280. Line from the verify help page for openssl: "Normally if an unhandled critical extension is present which is not supported by OpenSSL the certificate is rejected (as required by RFC3280 et al). If this option is set critical extensions are ignored." I'm guessing this has something to do with these stupid application extensions it has put on the certificate when generated from the Microsoft CA: X509v3 Basic Constraints: critical CA:FALSE X509v3 Key Usage: Digital Signature, Non Repudiation 1.3.6.1.4.1.311.21.7: 0..&+.7.Y../...z.=...z...@..d... X509v3 Extended Key Usage: critical Time Stamping 1.3.6.1.4.1.311.21.10: critical 0.0 Does anyone out there have any experience with generating certificates from Microsoft CA without these unknown extensions? I'm guessing in this case it's the 1.3.6.1.4.1.311.21.10. Application Policies extension -- same encoding as szOID_CERT_POLICIES szOID_APPLICATION_CERT_POLICIES 1.3.6.1.4.1.311.21.10 ^^ from some Microsoft page. Any ideas?? Thanks, Brad No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.339 / Virus Database: 270.12.46/2142 - Release Date: 06/02/09 17:53:00
