Re: Verify X.509 certificate, openssl verify returns bad signature
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. BER is already 'distinguished concerning the content octets of an INTEGER. X.690: 8 Basic encoding rules ... 8.3 Encoding of an integer value 8.3.1 The encoding of an integer value shall be primitive. The contents octets shall consist of one or more octets. 8.3.2 If the contents octets of an integer value encoding consist of more than one octet, then the bits of the first octet and bit 8 of the second octet: a) shall not all be ones; and b) shall not all be zero. NOTE – These rules ensure that an integer value is always encoded in the smallest possible number of octets. 8.3.3 The contents octets shall be a two's complement binary number equal to the integer value, and consisting of bits 8 to 1 of the first octet, followed by bits 8 to 1 of the second octet, followed by bits 8 to 1 of each octet in turn up to and including the last octet of the contents octets. NOTE – The value of a two's complement binary number is derived by numbering the bits in the contents octets, starting with bit 1 of the last octet as bit zero and ending the numbering with bit 8 of the first octet. Each bit is assigned a numerical value of 2N,where N is its position in the above numbering sequence. The value of the two's complement binary number is obtained by summing the numerical values assigned to each bit for those bits which are set to one, excluding bit 8 of the first octet, and then reducing this value by the numerical value assigned to bit 8 of the first octet if that bit is set to one. Chapter 10 and 11 don't say anything about INTEGER. The length field in definite encoding may have redundant zeros though in BER DER: 10.1 Length forms The definite form of length encoding shall be used, encoded in the minimum number of octets. [Contrast with 8.1.3.2 b).] __ 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-dev] Re: Verify X.509 certificate, openssl verify returns bad signature
Hodie IV Kal. Sep. MMX, Mounir IDRASSI scripsit: [...] 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. This is the kind of advice that pushes programmers to allocate fixed size fields in databases, and consider a certificate's serial number to always fit the size. This is also bad in practice. -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Another problem with certificate verification...
Greetings I have another problem with certificate verification. I get the same error as always with a testing CA we created... we have issued a certificate signed by this CA but we get the same error: *error 20 at 0 depth lookup:unable to get local issuer certificate* After checking if the problem is the same as the previous mail I sent, I can see that now everything looks good... The hierarchy is the following: acindenova - admesigna First, I started checking the issuer of the certificate /[amsterdam:/morralla/ttormo/ACIndenova]# openssl x509 -in admesigna.cer -issuer -noout issuer= /C=ES/O=AC Indenova SL - CIF B97458996/OU=http://www.indenova.com/CN=AC Indenova/ and the subject of the CA certificate: /[amsterdam:/morralla/ttormo/ACIndenova]# openssl x509 -in acindenova.cer -subject -noout subject= /C=ES/O=AC Indenova SL - CIF B97458996/OU=http://www.indenova.com/CN=AC Indenova/ Then match. I also tried checking the hashes / [amsterdam:/test]# openssl x509 -in admesigna.cer -issuer_hash -noout 042cc227/ / [amsterdam:/test]# openssl x509 -in acindenova.cer -subject_hash -noout 042cc227 /They also match... Then I checked the CA certificate key usages:/ [amsterdam:/morralla/ttormo/ACIndenova]# openssl x509 -in acindenova.cer -text Certificate: Data: Version: 3 (0x2) Serial Number: 14:19:c1:49:c9:86:cb:cc Signature Algorithm: sha1WithRSAEncryption Issuer: C=ES, O=AC Indenova SL - CIF B97458996, OU=http://www.indenova.com, CN=AC Indenova Validity Not Before: Dec 8 08:31:12 2006 GMT Not After : Dec 5 08:41:12 2016 GMT Subject: C=ES, O=AC Indenova SL - CIF B97458996, OU=http://www.indenova.com, CN=AC Indenova Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:99:04:75:cc:b8:2b:d9:d4:8e:6a:ed:ab:cd:a9: 34:f8:43:31:41:78:46:54:eb:f4:2c:7f:83:0d:01: 92:e5:2f:b6:1a:1f:73:f5:41:2d:df:1d:54:1e:10: ff:46:10:27:eb:b4:1a:99:26:bb:fb:2b:f2:3d:d5: 2d:d2:8d:fc:9b:4e:c1:ae:2b:8a:8f:f0:7f:d8:3e: 7a:be:27:6f:5c:f6:40:50:a3:a4:02:73:86:25:5e: 71:92:f6:58:68:c6:27:38:40:6f:51:6f:f7:e4:89: f2:47:e4:68:a0:ec:73:43:df:a3:46:03:24:61:14: 07:dc:c4:d5:32:c5:0a:4a:ab:13:e8:5e:e9:57:2e: 24:66:45:d2:f1:cd:35:fa:76:59:83:f7:1d:c5:96: 15:ed:d6:62:53:94:60:b5:17:56:4a:f6:ff:9b:45: 00:81:62:51:42:da:df:c4:73:9d:19:d1:c9:7c:7a: b5:34:6c:25:ac:9b:fd:36:dc:07:db:36:93:0b:21: 62:b2:e2:44:bf:ed:3c:3d:6f:01:03:ef:81:ca:a9: 90:87:3d:c7:63:2c:ad:95:b8:73:93:a0:d8:88:89: 4b:e3:be:9b:8a:33:3c:09:cd:9e:20:ce:05:ea:b8: 6b:df:c8:4c:d0:32:73:b9:85:3a:47:37:e9:c7:07: 3b:f5 Exponent: 3 (0x3) X509v3 extensions: *X509v3 Basic Constraints: critical CA:TRUE, pathlen:10 X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign* X509v3 Subject Key Identifier: B2:D2:89:54:6C:14:8E:84:CC:F4:DA:26:6A:45:9C:27:A9:5C:02:CF X509v3 Authority Key Identifier: keyid:B2:D2:89:54:6C:14:8E:84:CC:F4:DA:26:6A:45:9C:27:A9:5C:02:CF DirName:/C=ES/O=AC Indenova SL - CIF B97458996/OU=http://www.indenova.com/CN=AC Indenova serial:14:19:C1:49:C9:86:CB:CC X509v3 CRL Distribution Points: URI:http://crl.indenova.com/indenova.crl X509v3 Subject Alternative Name: email:inden...@indenova.com X509v3 Issuer Alternative Name: email:inden...@indenova.com X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.17326.10.9.2.2.2 CPS: http://cps.indenova.com/cps/csc.html User Notice: Explicit Text: Qualified Certificate. Registrant:Endesa RA https://subjetstatement.camerfirma.com/SN.html qcStatements: 0 0..F.. Signature Algorithm: sha1WithRSAEncryption 59:70:ae:d5:7b:2e:60:8b:6c:20:83:ec:7f:c3:9b:42:6f:13: cf:e8:d5:2a:a0:44:01:65:b4:83:22:cc:79:cc:be:c5:61:86: c8:b6:d0:79:97:b9:50:03:38:1c:f6:c0:23:dd:5d:b7:97:dc: d6:a6:e4:e2:60:73:55:09:6f:e6:56:a5:19:f0:b3:38:b2:ee: 3b:c1:1b:c0:f3:b5:ca:c3:48:c2:ed:f9:dd:a9:88:7c:b8:87: d6:20:28:b1:1f:01:e7:2e:d4:2b:0a:23:0a:60:61:e9:e5:dc: 87:18:bb:9d:5c:a3:cb:17:97:68:b6:36:22:53:8d:c0:81:a6: 97:d7:55:16:6c:16:01:f1:62:72:c4:d9:20:96:cf:af:48:66: 0d:25:66:54:87:68:c8:31:66:2f:fc:6f:24:3f:c9:51:2d:84:
Re: [openssl-users] Another problem with certificate verification...
Hodie III Kal. Sep. MMX, Tomás Tormo scripsit: [...] [amsterdam:/morralla/ttormo/ACIndenova]# openssl x509 -in acindenova.cer -text [...] Not Before: Dec 8 08:31:12 2006 GMT Not After : Dec 5 08:41:12 2016 GMT [...] [amsterdam:/test]# openssl x509 -in admesigna.cer -text Certificate: [...] Not Before: May 10 12:25:25 2010 GMT Not After : May 7 12:35:25 2020 GMT [...] Maybe OpenSSL doesn't like the fact that your EE certificate lasts longer than its CA? Anyway, other things: - e=3 is not considered good - will your Root CA sign something else than certificates and CRLs? If not, there's no use for the digitalSignature flag in keyUsage extension - a CRLDP in a Root is useless. Trust comes off-band, end of trust will also come off-band - a certificatePolicies extension in a Root is useless, it won't be processed at all if one follows the normative algorithm - netscapeCertType is of no use in 2010 - in your EE cert, qcStatements extension, you placed the 0.4.0.1862.1.1 OID twice. Useless, once is enough - in your EE cert, you added an AIA extension with an empty OCSP URI. Bad. - in your EE cert, you added an AIA extension with a CAIssuers field, but the considered CA is a self-signed one, so it has no other issuer than itself, so it's useless - in your EE cert, you specified a policy in your certificatePolicies extension. While this particular example is correct, that's just because a compliant implementation will ignore the OID used on the Root. If a non compliant one takes the Root OID in consideration, then it will fail -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Another problem with certificate verification...
On Mon, Aug 30, 2010, Toms Tormo wrote: Finally, I checked the Authority Key Identifier of the EE certificate but it looks good to me... /[amsterdam:/test]# openssl x509 -in admesigna.cer -text keyid:B2:D2:89:54:6C:14:8E:84:CC:F4:DA:26:6A:45:9C:27:A9:5C:02:CF DirName:/C=ES/O=AC Indenova SL - CIF B97458996/OU=http///www.indenova.com/CN=AC Indenova serial:14:19:C1:49:C9:86:CB:CC* Could anybody give me some clue about this? Thank you very much. If you include the -issuer_checks option you can soon diagnose the problem. You will see lots of messages about subject issuer mismatches: that's normal. Anything else may indicate a problem. In this case you get: error 31 at 0 depth lookup:authority and issuer serial number mismatch That is specifically indicating a problem with AKID. Looking above I can see http/// in AKID. I'd actually recommend not including the issuer and serial number in AKID if you can and just using the keyid option. Newer OpenSSL default configuration files do that. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ 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
У нед, 29. 08 2010. у 04:17 +0200, Mounir IDRASSI пише: 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. Thank you, I can confirm that your suggestion is working. Applying a patch that you described does solve a problem for me. The MUPCAGradjani certificate can be verified against the MUPCARoot, as well as certificates issued by the MUPCAGradjani, like the two personal certificates I have on my eID card. I had to reconvert DER to PEM with patched openssl to get PEM certificates with correct serial number encoding. I read the other messages in this thread, but I am not an expert in the field so I do not know if openssl should add a support for incorrect serial numbers. In RFC 3280 there is a note about Non-conforming CAs where section 4.1.2.2 Serial number is saying that certificate users SHOULD be prepared to gracefully handle such certificates. Maybe the note can apply in this case? What I do know is that without a patch openssl can not be used with certificates issued on a Serbian national eID card. At least one other Serbian CA is hit by the same problem (http://ca.pks.rs/certs/) where PKI solution was provided by a same company. I have published patched openssl package for Ubuntu GNU/Linux distribution in my Ubuntu PPA at: https://launchpad.net/~grakic/+archive/serbian-eid Kind regards, Goran Rakic __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: Verify X.509 certificate, openssl verify returns bad signature
Hodie III Kal. Sep. MMX, Goran Rakic scripsit: [...] I read the other messages in this thread, but I am not an expert in the field so I do not know if openssl should add a support for incorrect serial numbers. In RFC 3280 there is a note about Non-conforming CAs where section 4.1.2.2 Serial number is saying that certificate users SHOULD be prepared to gracefully handle such certificates. Maybe the note can apply in this case? What I do know is that without a patch openssl can not be used with certificates issued on a Serbian national eID card. At least one other Serbian CA is hit by the same problem (http://ca.pks.rs/certs/) where PKI solution was provided by a same company. These are not X.509 certificates, since they're not correctly encoded (not DER, not even BER). The paragraph you're mentioning is about the value of the serial number (strictly positive, no more than 20 bytes), not about its encoding. A serial number can be negative, or larger than 20 bytes when encoded, if your only goal is to be X.509 compliant, and not RFC5280 compliant. Whence, non-conforming CAs here is to be understood as non-RFC5280-conforming CAs. Those certificates should have been rejected by any correct validator (human or machine) before going into production. The serial number is encoded using 4 bytes as its value, it should be 1 byte only. -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Connection Resetting
Dave, Thank you for the clarification on HTTP keep-alives. I have just now fixed the bug. The source of the problem was an SSL_read call on the client half of the proxy. This was triggering an error SSL_ERROR_SYSCALL with a ret of zero. According to the documentation this is normally caused by an improperly shutdown SSL connection, however rescheduling the read for when the socket was ready (using a select statement) fixed this issue. I have tested it up to a 5MB file, and it works perfectly. I am a little confused on why I was getting the error in the first place still though. What would cause SSL_ERROR_SYSCALL to be flagged, and have an empty error queue if the socket was not closed improperly on the other side? On Sun, Aug 29, 2010 at 11:06 PM, Dave Thompson dthomp...@prinpay.comwrote: 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 -- Sam Jantz Software Engineer
Re: Verify X.509 certificate, openssl verify returns bad signature
On Mon, Aug 30, 2010, Goran Rakic wrote:
?? ??, 29. 08 2010. ?? 04:17 +0200, Mounir IDRASSI :
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.
Thank you, I can confirm that your suggestion is working.
Applying a patch that you described does solve a problem for me. The
MUPCAGradjani certificate can be verified against the MUPCARoot, as well
as certificates issued by the MUPCAGradjani, like the two personal
certificates I have on my eID card. I had to reconvert DER to PEM with
patched openssl to get PEM certificates with correct serial number
encoding.
I read the other messages in this thread, but I am not an expert in the
field so I do not know if openssl should add a support for incorrect
serial numbers. In RFC 3280 there is a note about Non-conforming CAs
where section 4.1.2.2 Serial number is saying that certificate users
SHOULD be prepared to gracefully handle such certificates. Maybe the
note can apply in this case?
What I do know is that without a patch openssl can not be used with
certificates issued on a Serbian national eID card. At least one other
Serbian CA is hit by the same problem (http://ca.pks.rs/certs/) where
PKI solution was provided by a same company.
I have published patched openssl package for Ubuntu GNU/Linux
distribution in my Ubuntu PPA at:
https://launchpad.net/~grakic/+archive/serbian-eid
I wouldn't advise changing the code in that way (FYI I wrote it). The normal
workaround in OpenSSL for broken encodings is to use the original encoding
by caching it. The attached three line patch adds this workaround for
certificates.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
Index: crypto/asn1/x_x509.c
===
RCS file: /v/openssl/cvs/openssl/crypto/asn1/x_x509.c,v
retrieving revision 1.29
diff -u -r1.29 x_x509.c
--- crypto/asn1/x_x509.c8 Aug 2008 15:35:27 - 1.29
+++ crypto/asn1/x_x509.c29 Aug 2010 23:08:35 -
@@ -63,7 +63,7 @@
#include openssl/x509.h
#include openssl/x509v3.h
-ASN1_SEQUENCE(X509_CINF) = {
+ASN1_SEQUENCE_enc(X509_CINF, enc, 0) = {
ASN1_EXP_OPT(X509_CINF, version, ASN1_INTEGER, 0),
ASN1_SIMPLE(X509_CINF, serialNumber, ASN1_INTEGER),
ASN1_SIMPLE(X509_CINF, signature, X509_ALGOR),
@@ -74,7 +74,7 @@
ASN1_IMP_OPT(X509_CINF, issuerUID, ASN1_BIT_STRING, 1),
ASN1_IMP_OPT(X509_CINF, subjectUID, ASN1_BIT_STRING, 2),
ASN1_EXP_SEQUENCE_OF_OPT(X509_CINF, extensions, X509_EXTENSION, 3)
-} ASN1_SEQUENCE_END(X509_CINF)
+} ASN1_SEQUENCE_END_enc(X509_CINF, X509_CINF)
IMPLEMENT_ASN1_FUNCTIONS(X509_CINF)
/* X509 top level structure needs a bit of customisation */
Index: crypto/x509/x509.h
===
RCS file: /v/openssl/cvs/openssl/crypto/x509/x509.h,v
retrieving revision 1.171
diff -u -r1.171 x509.h
--- crypto/x509/x509.h 14 Mar 2010 12:52:38 - 1.171
+++ crypto/x509/x509.h 29 Aug 2010 23:04:30 -
@@ -258,6 +258,7 @@
ASN1_BIT_STRING *issuerUID; /* [ 1 ] optional in v2 */
ASN1_BIT_STRING *subjectUID;/* [ 2 ] optional in v2 */
STACK_OF(X509_EXTENSION) *extensions; /* [ 3 ] optional in v3 */
+ ASN1_ENCODING enc;
} X509_CINF;
/* This stuff is certificate auxiliary info
Re: Verify X.509 certificate, openssl verify returns bad signature
У пон, 30. 08 2010. у 20:38 +0200, Dr. Stephen Henson пише: I wouldn't advise changing the code in that way (FYI I wrote it). The normal workaround in OpenSSL for broken encodings is to use the original encoding by caching it. The attached three line patch adds this workaround for certificates. Thanks Stephen. This preprocessor black magic looks very interesting, I will spend some free time trying to understand it in the following days. I read your message on openssl-dev about the issue with a dirty cache. As a naive code reader, I am wondering could not the modified field in the cached data be set whenever certificate data is modified to invalidate the cache? Will this allow integrating this patch upstream? Kind regards, Goran Rakic __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Tls max fragment length problem
Hi, Sorry I made a mistake with question 3 due to my mis-understanding of plaintext. It is actually the same question as question 1. Actually I can control the TLS record size when calling SSL_write by restricting the buffer size of each iterative. However, I couldn't control the size in communication done by OpenSSL lib when establishing the connection. The size simply exceed the expected limit (512 bytes) when a whole certificate chain is transferred. So far I haven't find any solution other than modifying the macro value. However, due to some reasons it's best to avoid modifying the source code. Any help is appreciated. regards, Peter Lin On Sat, Aug 28, 2010 at 11:52 AM, peterlingoal peterling...@gmail.comwrote: Hi everyone, I have three questions: 1. Is there any API to limit the TLS fragment length (record size) to a smaller value than default (2^14)? 2. How to set TLS extension max_fragment_length as suggested in RFC4366? From the source code of 0.9.8l and mailing achieve it seems that this has not been implemented. 3. Is there any API to define the maximumly allowed TLS plaintext length in a TLS record? If not will changing the macro SSL3_RT_MAX_PLAIN_LENGTH value serving the purpose? Please comment. Thanks. regards, Peter Lin
Re: Verify X.509 certificate, openssl verify returns bad signature
On Mon, Aug 30, 2010, Goran Rakic wrote: ?? ??, 30. 08 2010. ?? 20:38 +0200, Dr. Stephen Henson : I wouldn't advise changing the code in that way (FYI I wrote it). The normal workaround in OpenSSL for broken encodings is to use the original encoding by caching it. The attached three line patch adds this workaround for certificates. Thanks Stephen. This preprocessor black magic looks very interesting, I will spend some free time trying to understand it in the following days. Well it is buried in the ASN1 code. All it does is uses an extra structure to save the received encoding. Then when signatures are calculated that is used instead of re-encoding the parsed out structure. I read your message on openssl-dev about the issue with a dirty cache. As a naive code reader, I am wondering could not the modified field in the cached data be set whenever certificate data is modified to invalidate the cache? Will this allow integrating this patch upstream? It isn't possible to cover all cases where the certificate data is modified as some don't keep a reference to the parent certificate structure. However it is possible to always re-encode when a certificate is signed (this is done for CRLs) which should cover all cases except pathological ones where a certificate is modified and not re-signed to deliberately produce invalid signatures. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
