[openssl.org #2732] Bug: verification fails if muliple certification path (EV/Verisign)
Same problem apply for cross-certificates which create multiple paths also. Imagine the expiring CA (expiring within year or two, not expired already). The organization will create the new one, but want to maintain transition period for the users. So create two cross certificates - the public of oldCA will sign by new CA and vice versa. So resulting structure is: a) public key of newCA is selfsigned, creating root certificate of new tree b) same public key is signed by oldCA with CA:TRUE attribute, creating certificate of intermediate CA authority within old tree End servers with certificate issued by (newCA|intermediate CA) should send following chain: s: /CN=EndCertificate i: /CN=newCA s: /CN=newCA # This is intermediate CA certificate i: /CN=oldCA Scenario 1: User is not aware of existence newCA yet (but oldCA is still not expired and trusted by user). Verification: EndCertificate issued by (newCA|intermediate CA) issued by oldCA Conclusion: certificate considered trusted Scenario 2: User trusting newCA. Verification: EndCertificate issued by (newCA|intermediate CA) which is considered trusted by user, no further steps required Conclusion: certificate considered trusted Unfortunately, scenario 2 doesn't work with OpenSSL. End-of-chain certificates are verified against trusted store only. So painless transition from one CA to other CA is not possible Dan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1588] Already resolved in other ticket, please close
Same issue has been reported and resolved in #1624. This report can be closed. Dan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2754] Ugly interaction of (openssl x509)'s option -x509toreq with -outform/-text/-noout
About year ago, the apps/x509.c has been patched not to ignore -keyform during -x509toreq operation. IMHO it's proper time to patch not to ignore other options as well. All following text is related to "openssl req -x509toreq" call. Current behavior: 1. -outform is ignored, PEM format used all the times 2. output contain text representation of created request all the time, despite of '-text' option is used or not 3a. -text -x509toreq sequence results to following output sequence: [text representation of source x509 certificate] [text representation of resulting request] [resulting request in PEM format] 3b. -x509toreq -text sequence results to following output sequence: [text representation of resulting request] [resulting request in PEM format] [text representation of source x509 certificate] 3c. -x509toreq -text or -text -x509toreq sequences combined with -noout in any position results to following output sequence: [text representation of source x509 certificate] --- Proposed behavior: 1. honor the -outform 2,3. print text representation of resulting request when -text requested only, then print resulting request in DER or PEM format unless -noout specified, don't print text representation of source x509 certificate in -x509toreq mode at all. It results to following output sequence: IF -textTHEN [text representation of resulting request] IF ! -noout THEN [resulting request in $( outform) format] I wish [1] need no more explanation. According to 2&3 - I assume the current behavior is not intentional. I wish the proposed behavior is more consistent with x509 app behavior in non x509toreq mode as well as behavior of other apps. Patch is attached. Best regards Dan Lukes patch-DAN-apps::x509.c Description: application/unregisterd-mime-type-to-avoid-ie-mime-sniffing
[openssl.org #1588] Bug report with PATCH
>Synopsis: /dev/crypto broken on FreeBSD >Class: sw-bug >OS Release: FreeBSD 6.2-RELEASE-p8 i386 >OpenSSL Release: All OpenSSL releases based on crypto/engine/eng_cryptodev.c v.1.5 and newer (tested on 0.9.8e) >Description: The problem check-in #11541 http://cvs.openssl.org/chngview?cn=11541 commited to crypto/engine/eng_cryptodev.c 1.4 -> 1.5 broke the /dev/crypto support on FreeBSD The current code contain: -- ... if (defined(__unix__) || defined(unix)) && !defined(USG) && \ (defined(OpenBSD) || defined(__FreeBSD_version)) #include ... -- Unfortunately, the __FreeBSD_version variable is defined within sys/param.h As the #if check the presence of such variable before the sys/param inclusion, it fail everytime so /dev/crypto support is not compiled in. >How-To-Repeat: Run the 'openssl speed' on FreeBSD with and without a /dev/crypto supported hardware accelerator, compare the results >Fix: We can check the existence of variables, but after the sys/param.h inclusion only. See the attached patch. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #912] Re: [PATCH] Back-translation of CA.pl into CA.sh
Stephen Henson via RT wrote: >>I back-translated the current version of CA.pl back into CA.sh. ... >> there are no reason for using as strong tool as perl for this simple task > There is at least one reason for the perl translation. Some of the many > platforms OpenSSL compiles on have will have perl installed (well by > virtue of the fact that this is mandatory) but no bourne shell, Windows > is one such case. BTW, the CA.sh use no extensions of Bourne shell (which is, by default, present on Linux only, AFAIK). It should be interpretable by original Korn shell (old good "sh"), e.g. on almost every UNIX-like OSs. Of course, the Windows remain an example of OS without Korn-shell compatible command interpretter ... Thank you for your comment. Dan __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
