Re: Verify X.509 certificate, openssl verify returns bad signature
The encoding is invalid BER. The openssl is tolerant but also destructive in copy. whenever you use openssl x509 -in -out ... you remove one leading 0 octet. IMHO openssl should reject the cert because of invalid encoding. On 08/29/2010 04:17 AM, Mounir IDRASSI wrote: Hi, The problem you are encountering is partly caused by the way OpenSSL handles integers whose DER encoded value starts with one or more zeros : in this case, OpenSSL removes the leading zero when creating the corresponding ASN1_INTEGER structure thus leading to the fact that computed DER of this structure and the original one will be different!! In your case, the certificate you are trying to verify has a DER encoded serial number 00 00 65. So, OpenSSL will create an ASN1_INTEGER with a value of 00 65. And in the course of the certificate signature verification, this structure will be encoded to DER which will lead to a encoded value of 00 65. Thus, the generated DER of the CertInfo will be different from the original one, which explains why the signature verification fails. After some digging, I found that part of the problem is caused by the functions c2i_ASN1_INTEGER and d2i_ASN1_UINTEGER in file crypto\asn1\a_int.c. At lines 244 and 314, there is an if block that removes any leading zeros. Commenting out these blocks solves the DER encoding mismatch but the verification still fails because the computed digest is different from the recovered one. I will continue my investigation to find all the culprits. Meanwhile, the question remains why in the first place the removal of the leading zero from the parsed DER encoding was added since this clearly have the side effect of making the computed DER different from the original one. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr On 8/28/2010 10:43 PM, Goran Rakic wrote: Hi all, I have two X.509 certificates MUPCAGradjani.crt and MUPCARoot.crt downloaded from http://ca.mup.gov.rs/sertifikati-lat.html Certificate path is MUPCARoot MUPCAGradjani and I would like to validate MUPCAGradjani against the other. What I did is to convert both to PEM format and rename them by hash as efd6650d.0 (Gradjani) and fc5fe32d.0 (Root) using this script: #!/bin/bash hash=`openssl x509 -in $1 -inform DER -noout -hash` echo Saving $1 as $hash.0 openssl x509 -in $1 -inform DER -out $hash.0 -outform PEM Now I run: $ openssl verify -CApath . efd6650d.0 error 7 at 0 depth lookup:certificate signature failure 16206:error:04077068:rsa routines:RSA_verify:bad signature:rsa_sign.c:255: 16206:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:173:/pre Hm, that is not working. What am I doing wrong here? I am running OpenSSL 0.9.8k 25 Mar 2009 on Ubuntu 10.04 GNU/Linux. I also have my personal certificate issued by MUPCAGradjani that I would like to verify but it is failing with the same error (just one level down): $ openssl verify -CApath . qualified.pem qualified.pem: /CN=MUPCA Gradjani/O=MUP Republike Srbije/L=Beograd/C=Republika Srbija (RS) error 7 at 1 depth lookup:certificate signature failure 16258:error:04077068:rsa routines:RSA_verify:bad signature:rsa_sign.c:255: 16258:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:173:/pre When I install downloaded certificates in Windows using Internet Explorer and doubleclick on my personal certificate (qualified.cer) it looks valid. I am not sure, but I believe it is doing certificate chain validation so the certificates and paths should be valid. After all they are issued by a trustful CA. Output of openssl x509 -nameopt multiline,utf8,-esc_msb -noout -text -in $1 looks reasonable for both downloaded certificates and is the same before and after conversion to PEM (using -inform DER in the first case). My take on this is that I am not doing conversion properly or maybe the original certificates are in some other format requiring extra argument, but I can not find answer in the docs. How can I properly validate X.509 certificate from http://ca.mup.gov.rs/sertifikati-lat.html by certificate chain? Kind regards, Goran __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-...@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List
Re: Verify X.509 certificate, openssl verify returns bad signature
Hi Peter, Although the certificate's encoding of the serial number field breaks the BER specification about the minimal bytes representation, it is known that many CA's and libraries treat this field as a blob and usually encode it on a fixed length basis without caring about leading zeros. Specifically, Peter Gutmann in his X.509 Style Guide says this about this field : If you're writing certificate-handling code, just treat the serial number as a blob which happens to be an encoded integer. Moreover, major PKI libraries are tolerant vis-a-vis the encoding of the serial number field of a certificate and they verify successfully the certificate chain given by the original poster. For example, NSS, GnuTLS and CryptoAPI accept the given certificates and verify successfully their trust. Supporting or not specific broken implementations have always been the subject of heated debates. Concerning the specific issue here, it's clear that OpenSSL is too restrictive compared to other major libraries since this is a minor deviation from the BER specs (i.e. minimal bytes representation) and thus hurts deployments of real-world certificates. -- Mounir IDRASSI IDRIX http://www.idrix.fr The encoding is invalid BER. The openssl is tolerant but also destructive in copy. whenever you use openssl x509 -in -out ... you remove one leading 0 octet. IMHO openssl should reject the cert because of invalid encoding. On 08/29/2010 04:17 AM, Mounir IDRASSI wrote: Hi, The problem you are encountering is partly caused by the way OpenSSL handles integers whose DER encoded value starts with one or more zeros : in this case, OpenSSL removes the leading zero when creating the corresponding ASN1_INTEGER structure thus leading to the fact that computed DER of this structure and the original one will be different!! In your case, the certificate you are trying to verify has a DER encoded serial number 00 00 65. So, OpenSSL will create an ASN1_INTEGER with a value of 00 65. And in the course of the certificate signature verification, this structure will be encoded to DER which will lead to a encoded value of 00 65. Thus, the generated DER of the CertInfo will be different from the original one, which explains why the signature verification fails. After some digging, I found that part of the problem is caused by the functions c2i_ASN1_INTEGER and d2i_ASN1_UINTEGER in file crypto\asn1\a_int.c. At lines 244 and 314, there is an if block that removes any leading zeros. Commenting out these blocks solves the DER encoding mismatch but the verification still fails because the computed digest is different from the recovered one. I will continue my investigation to find all the culprits. Meanwhile, the question remains why in the first place the removal of the leading zero from the parsed DER encoding was added since this clearly have the side effect of making the computed DER different from the original one. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr On 8/28/2010 10:43 PM, Goran Rakic wrote: Hi all, I have two X.509 certificates MUPCAGradjani.crt and MUPCARoot.crt downloaded from http://ca.mup.gov.rs/sertifikati-lat.html Certificate path is MUPCARoot MUPCAGradjani and I would like to validate MUPCAGradjani against the other. What I did is to convert both to PEM format and rename them by hash as efd6650d.0 (Gradjani) and fc5fe32d.0 (Root) using this script: #!/bin/bash hash=`openssl x509 -in $1 -inform DER -noout -hash` echo Saving $1 as $hash.0 openssl x509 -in $1 -inform DER -out $hash.0 -outform PEM Now I run: $ openssl verify -CApath . efd6650d.0 error 7 at 0 depth lookup:certificate signature failure 16206:error:04077068:rsa routines:RSA_verify:bad signature:rsa_sign.c:255: 16206:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:173:/pre Hm, that is not working. What am I doing wrong here? I am running OpenSSL 0.9.8k 25 Mar 2009 on Ubuntu 10.04 GNU/Linux. I also have my personal certificate issued by MUPCAGradjani that I would like to verify but it is failing with the same error (just one level down): $ openssl verify -CApath . qualified.pem qualified.pem: /CN=MUPCA Gradjani/O=MUP Republike Srbije/L=Beograd/C=Republika Srbija (RS) error 7 at 1 depth lookup:certificate signature failure 16258:error:04077068:rsa routines:RSA_verify:bad signature:rsa_sign.c:255: 16258:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:173:/pre When I install downloaded certificates in Windows using Internet Explorer and doubleclick on my personal certificate (qualified.cer) it looks valid. I am not sure, but I believe it is doing certificate chain validation so the certificates and paths should be valid. After all they are issued by a trustful CA. Output of openssl x509 -nameopt multiline,utf8,-esc_msb -noout -text -in $1 looks reasonable for
Need help with signing a csr with a openssl generated CA.
We're trying to generate self signed certs and don't seem to keep the attributes after a csr is signed by a self generated CA via openssl (i.e.: OIDs specified in openssl.cfg drop off the server cert after signed, thus creating a V1 cert). Here is an example of the syntax I'm using: Generate a CA Key: openssl genrsa -out ca.key 1024 Generate a CA certificate with the previous key: openssl req -new -x509 -days 3650 -key ca.key -out ca.crt Generate a server certificate key: openssl genrsa -out server.key 1024 Generate a certificate request with applying the server key as well: openssl req -new -out server.csr -key server.key Sign .csr with the CA cert key: openssl x509 -req -days 3650 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt And the openssl.cfg is adding the OIDs correctly based on running: openssl req -text -noout -in server.csr Here is the important part that shows the attributes are attached to the request: Attributes: Requested Extensions: X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment After signing it with the self-generated CA above, the server cert shows as a Version 1 (V1) cert and does not show the ServerAuth Client Auth in the server cert. Where did they go? Thanks! P.S. Here are some details of what I am using: - Windows XP Professional - openSSL 1.0.0.a 1 Jun 2010 - editing C:\OpenSSL-Win32\bin\openssl.cfg to apply OIDs or SubjectAltNames (will approach later). - Will use the certs for LDAP over SSL __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Need help with signing a csr with a openssl generated CA.
Hello, We're trying to generate self signed certs and don't seem to keep the attributes after a csr is signed by a self generated CA via openssl (i.e.: OIDs specified in openssl.cfg drop off the server cert after signed, thus creating a V1 cert). Here is an example of the syntax I'm using: Generate a CA Key: openssl genrsa -out ca.key 1024 Generate a CA certificate with the previous key: openssl req -new -x509 -days 3650 -key ca.key -out ca.crt Generate a server certificate key: openssl genrsa -out server.key 1024 Generate a certificate request with applying the server key as well: openssl req -new -out server.csr -key server.key Sign .csr with the CA cert key: openssl x509 -req -days 3650 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt And the openssl.cfg is adding the OIDs correctly based on running: openssl req -text -noout -in server.csr Here is the important part that shows the attributes are attached to the request: Attributes: Requested Extensions: X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment After signing it with the self-generated CA above, the server cert shows as a Version 1 (V1) cert and does not show the ServerAuth Client Auth in the server cert. Where did they go? Thanks! P.S. Here are some details of what I am using: - Windows XP Professional - openSSL 1.0.0.a 1 Jun 2010 - editing C:\OpenSSL-Win32\bin\openssl.cfg to apply OIDs or SubjectAltNames (will approach later). - Will use the certs for LDAP over SSL __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verify X.509 certificate, openssl verify returns bad signature
On 08/29/2010 01:20 PM, Mounir IDRASSI wrote: Hi Peter, Although the certificate's encoding of the serial number field breaks the BER specification about the minimal bytes representation, it is known that many CA's and libraries treat this field as a blob and usually encode it on a fixed length basis without caring about leading zeros. Specifically, Peter Gutmann in his X.509 Style Guide says this about this field : If you're writing certificate-handling code, just treat the serial number as a blob which happens to be an encoded integer. You are citing out of context. There is a reference to negative integers which can happen 50%. A text written 10 years ago is not really an excuse for a certificate from this year. Moreover, major PKI libraries are tolerant vis-a-vis the encoding of the serial number field of a certificate and they verify successfully the certificate chain given by the original poster. So what. The certs are still wrong. For example, NSS, GnuTLS and CryptoAPI accept the given certificates and verify successfully their trust. hm, inserting the certs into Firefox says to me that the certs cannot be validated for unknown reasons. The decoders in NSS and GnuTLS accept all kinds of bad encodings, the BER/DER decoders being very tolerant. Supporting or not specific broken implementations have always been the subject of heated debates. X509 has been updated to decode and reencode a certificate, in this sense openssl's behaviour of silently dropping one octet is not very nice. But there are other potential minor deviations. Concerning the specific issue here, it's clear that OpenSSL is too restrictive compared to other major libraries since this is a minor deviation from the BER specs (i.e. minimal bytes representation) and thus hurts deployments of real-world certificates. Others are EXTREMLY permissive in decoding. This minor deviation results in ambiguous DER. Assumed two values 0001 or 01, are these the same serialnumber, or not? This is asking for real trouble. Even when taking as a blob, displaying will show 1 for both in major implementations. I'd rather see openssl be more restrictive and reject bad encodings (I am not talking about a negative number here). and what about version: 02060002 020601230002 some treat the second as a v3 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verify X.509 certificate, openssl verify returns bad signature
On 08/29/2010 07:38 PM, Mounir IDRASSI wrote: Hi Peter, Thank you for your comments. As I said, this kind of debates can be very heated and going down this road don't lead usually to any results. The debate may be whether and how something should be done in openssl, I admit I had started that one. I am the first one to wish that the PKI world out there is ideal and everyone uses correctly validated modules. Unfortunately, we constantly have to balance between correctness and practicalness. Some programs are not strict in verification, so be it. But that has nothing to do with the fact that the certs in question are not correctly encoded and may create unexpected behaviour... Concerning Firefox check, I have managed to load the chain and to validate it correctly using Firefox 3.6.8 under Windows and Ubuntu 10.04. I'm attaching screenshots. Try edit the trustsetting. Or: Try load them without setting any trust during loading and to set some later through the certificate management. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Connection Resetting
From: owner-openssl-us...@openssl.org On Behalf Of Sam Jantz Sent: Friday, 27 August, 2010 18:16 I have a question concerning Keep-Alives. I'm writing a SSL proxy (which is working great except for this issue) and every time I [POST about 470KB rather than about 18KB] the connection resets, and it gets caught in an infinite retransmit loop. snip This behavior is only implemented in Firefox. In the other browsers it seems to fail out with some error about unexpected reset. Is there some parameter that I can set when establishing the SSL connection that will allow me to wait for larger transfers without reseting? 1. This has nothing to do with keep-alives. HTTP 1.1 keep-alive is a passive feature; it doesn't do anything, instead if agreed the server REFRAINS FROM closing the connection as it would for 1.0. 2. It sounds like the browser is getting RST. (Or to be exact, getting an error from the OS that *it* got RST.) Firefox might respond to this differently than other browsers, by retrying; I don't have time to test. If so, the RST is caused by your proxy doing something abnormal, most likely dying. Check your code for bugs, and/or your logs -- your program does have logging and diagnostic code in it, like any well-designed program, right? 3. Or do you think the proxy is getting RST from gmail? I am 99.99% certain google wouldn't have a problem that would do that, although it isn't completely impossible. It's much more likely to be some network (mis)feature between you and gmail, like a firewall, NAT box, access controller, transparent (but not really) cache, etc. Try without your proxy, but with a client (i.e. browser) on the machine where the proxy is, to the same server with the same amounts of data (or at least reasonably close). If you can, try from different places in the Internet, like from home or a Starbucks versus the company office. 4. SSL itself has no timelimits; it will wait forever, or until the underlying TCP connection fails. (If a remote host just dies without closing properly, TCP may detect this in anywhere from a few minutes to many hours or days, depending.) An application *using* SSL might have a timelimit; if so you have to look to that program as to how, and whether, you can change it. And sometimes a firewall or NAT box or such has an idle timeout, where it will terminate your connection if it isn't used for an excessive period of time, and some netadmins have a crazy idea what is excessive; but I've never seen less than 15 minutes, which I expect is not the case in your example. The really awful ones do this silently, or by faking FIN; the ones that fake(?) RST at least give you a detectable error. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Verify X.509 certificate, openssl verify returns bad signature
From: owner-openssl-us...@openssl.org On Behalf Of Peter Sylvester Sent: Sunday, 29 August, 2010 05:44 The encoding is invalid BER. The openssl is tolerant but also destructive in copy. whenever you use openssl x509 -in -out ... you remove one leading 0 octet. IMHO openssl should reject the cert because of invalid encoding. On 08/29/2010 04:17 AM, Mounir IDRASSI wrote: Hi, The problem you are encountering is partly caused by the way OpenSSL handles integers whose DER encoded value starts with one or more zeros : in this case, OpenSSL removes the leading zero when creating the corresponding ASN1_INTEGER structure thus leading to the fact that computed DER of this structure and the original one will be different!! Nit: redundant leading 00 (or FF) in an INTEGER is VALID *B*ER but INVALID *D*ER. And signed things like certs are *D*ER for exactly this reason, so a reconstructed encoding is bit for bit identical and hashes and signatures etc. work. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Fallback certs
From: owner-openssl-us...@openssl.org On Behalf Of Devin Ceartas Sent: Friday, 27 August, 2010 16:21 To: openssl-users@openssl.org Subject: Fallback certs Is it possible to have a preferred certificate (say, one I created myself and signed with my own root) and have connections to a web browser fall back on a secondary cert (say one from a commercial provider) if negotiation on the preferred certificate fails? Not really, at least not easily. There is no provision in SSL (or TLS AFAIK) for the client to ask for a different cert than the one provided, or to specify CAs. (Going the other way, for *client* auth, the server specifies a list of acceptable CAs, which the client can use to choose which cert=id to offer.) The choice of server cert does depend on the broad cipher 'type' negotiated, i.e. RSA, DSA+DH, ECDSA+ECDH. A programmed client could conceivably try negotiation with different ciphersuites offered until it gets a cert (and ciphersuite) it likes, but doing this with the web browsers I know is either impossible or so clumsy as to be unusable. Depending on how your server is programmed, you might be able to remember failed connection attempts by IPaddr, especially ones where you got a clear error indication like alert 46 or 48, and handle specially any new attempt from the same IPaddr within a reasonably short time like 5 seconds. You usually don't want to remember too many or too long, or that opens a denial of service attack against you. TLS1.1 (and I assume higher) does have an extension for Server Name Indication to support multiple virtual hosts (e.g. websites) on the same host (address) and port. I haven't looked how OpenSSL implements this (in terms of using it for a cert/key choice, or providing a callback to) and don't know whether/which common browsers send it. If yours do, and you don't mind telling different user populations to use a different hostname (or do it for them by providing emails or forms or whatever with different URLs), you could have virtual hosts that actually serve the same content (or different if you like) under different names. But in the end, why do you care? If you have a commercial cert that your (expected) users accept, why don't you just use it? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Need help with signing a csr with a openssl generated CA.
From: owner-openssl-us...@openssl.org On Behalf Of Andy GOKTAS Sent: Friday, 27 August, 2010 13:00 To: openssl-users@openssl.org Subject: Need help with signing a csr with a openssl generated CA. Hello, We're trying to generate self signed certs and don't seem to keep the attributes after a csr is signed by a self generated CA via openssl (i.e.: OIDs specified in openssl.cfg drop off the server cert after signed, thus creating a V1 cert). Note that a cert is NOT a (re)signed CSR. People often say so, but it's wrong. The cert signed part (certInfo aka body aka TBS) is quite *similar* to the body of a CSR, but *not* the same. That matters to your case because the code must explicitly put into the cert body everything that goes there, whether from the CSR or otherwise, including extensions. Here is an example of the syntax I'm using: Generate a CA Key: openssl genrsa -out ca.key 1024 Generate a CA certificate with the previous key: openssl req -new -x509 -days 3650 -key ca.key -out ca.crt Generate a server certificate key: openssl genrsa -out server.key 1024 Generate a certificate request with applying the server key as well: openssl req -new -out server.csr -key server.key Sign .csr with the CA cert key: openssl x509 -req -days 3650 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt x509 -req doesn't copy extensions from the CSR to the cert. It appears from the source that it will *add* extensions from the config file to the generated cert *if* you explicitly specify -extfile but not by default. I have no clue why, and haven't tested. ca, which generates certs from CSRs much like x509 -req, but also records them in a (trivial) database, and has since longer IIRC, does copy extensions by default, but can add to and/or suppress them per options in the configuration file. You should understand that the openssl commandline utilities mostly just grew over many years with features added and changed as the developers saw a need for them -- perhaps based on many user requests, perhaps only a few (but maybe paid), and perhaps none, it just seemed like something fun to do. Some efforts have been made from time to time to make parts of them consistent and/or complete, but there has clearly not been enough labor available to do everything. It looks like you're using the ShiningLight build, which doesn't include source (at least last I looked), but you can get it from www.openssl.org/source and change it (at least for your own use) if you want. Personally I would just use ca. snip rest __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
