openssl configuration & cert validity checking
I think someone has touched on some of this on the list recently, but I was curious if there was a way to programmatically (through an API call or other) way to patch into OpenSSL's configuration capability - I understand the library by default looks at text files on a file system for things like root certificates, but if I'm running on an embedded system with no hard drive and I don't have a persistent storage medium accessible through traditional file I/O calls, how would I feed OpenSSL everything it needs to operate correctly? Also, because I'm on an embedded system, I can't download CRLs to a file on a file system because of limited storage. I either have to download delta-CRLs (which is no guarantee of a small download), or have a way to "stream" CRL data through a verifier process. In this way, certificates are checked against a CRL while the data is being downloaded into the embedded device. After CRL records have been processed, they're thrown away. If we have a "match" in a CRL, we can cache that cert as being "revoked" - like a "lookaside list" that we check prior to downloading a CRL. Of course the "revoked cert" cache would not be persistent because we may not have non-volatile memory to store the cache. If we're using OCSP, a file system is not really an issue, and we can cache OCSP responses as well, as supported by the protocol. Any information on API configuration of all openssl parameters (no text files) and certificate validation on a constrained embedded device is much appreciated. Thanks! Randy __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
OCSP documentation
Is there any documentation on how I can programmatically create OCSP requests, ready to be sent on the wire? Thanks in advance! Randy __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cryptographic Hardware Accelerators for OpenSSL
I'm assuming it's also possible to statically link/bind (at build time) engine drivers. Is this the case? R. On Feb 16, 2006, at 3:50 PM, Dr. Stephen Henson wrote: On Thu, Feb 16, 2006, Lech Olmedo wrote: My intent is trying to add as a new Engine some crypto modules from a Coldfire device..., but after reading some information and some links, it seem that it is not possible... is this correct? I'm not sure what would make you think it isn't possible. The preferred way is to compile then engine as a shared library and then it can be loaded and used either using the auto config mechanism (if the application supports it) or by installing it in the appropriate directory and using its name. For example looking up an engine called "coldfire" might try to load a shared library called "libcoldfire.so" Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
multi-thread support
Hi All, I just wanted to verify that, as of OpenSSL 0.9.8a, any OpenSSL data facility that utilizes "STACK_OF" as a container for different types of objects, the routines that reference these "stacks" do not support multiple threads accessing the same "stack". Is this the case? I didn't see any mutex/user callback support in stack.c. Thanks! Randy __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: calling SSL_library_init multiple times
The first sentence of the explanation below seems to infer that its ok to call ssl_library_init() from each thread that might want to access the SSL library. I don’t think that’s what was intended. I think the last sentence is more accurate – if you have a multi-threaded application, and you’ve “hooked” the static and dynamic mutex functions to allow OpenSSL to correctly operate in a multi-threaded environment, then SSL_library_init() should only be called once, during application initialization. This single call will initialize the library for all threads. This is my interpretation of from what I have gleaned from the docs and sources. Randy From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jagannadha Bhattu G Sent: Tuesday, February 28, 2006 1:42 AM To: openssl-users@openssl.org Subject: Re: calling SSL_library_init multiple times Thanks Nils and Andrew for the replies. -JB On 2/27/06, Nils Larsch <[EMAIL PROTECTED]> wrote: Jagannadha Bhattu G wrote: > Hi, > > Can I call SSL_library_init multiple times in my code under different > threads? as SSL_library_init() initializes global tables it should only be called from one thread a time and of course no other thread should use the global data while SSL_library_init() is running. Ideally it should be run once before the threads using ssl are created. > From the documented return values, it always returns 1 but this doesn't mean it's reentrant Cheers, Nils __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Choice of CAs in SSL/TLS handshake
When you want to operate in this special "CA filtering" mode, you could hook the OpenSSL certificate validation logic. Your callback could then implement it's only validation logic and return a "reject" when you see a certificate you want to deny (even though it's valid). Randy On Mar 7, 2006, at 7:03 AM, Olaf Gellert wrote: Samy Thiyagarajan wrote: Hi, May be changing the verification of the depth level solve this issue. ( I mean check the chain only upto User CA 1 and not upto the Root CA ) In this case it should not report about missing valid root. Im not sure. this is just an idea. Good idea. But unfortunately it does not work out. I removed the root-certificate from the SSLCACertificateFile. The Server now only allows the user CA 1 (otherwise it still offers the root CA as valid CA). And I shortened the verifyDepth to one. But the server denies access saying: [Tue Mar 07 15:56:34 2006] [error] Certificate Verification: Error (20): unable to get local issuer certificate Seems that "verifyDepth" still requires a self-signed root certificate (so the chain has to reach the toplevel in the given number of steps). Hm... Any other proposals? :-) Cheers, Olaf -- Dipl.Inform. Olaf Gellert PRESECURE (R) Senior Researcher, Consulting GmbH Phone: (+49) 0700 / PRESECURE [EMAIL PROTECTED] A daily view on Internet Attacks https://www.ecsirt.net/sensornet __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: A little help would be appreicated
Hi Stephen, There have been a few email messages on the list recently concerning negative attributes of 0.9.8, with recommendations of using 0.9.7.x versions. Are we to assume that later versions of 0.9.7.x are really preferred for creating robust solutions with OpenSSL, instead of 0.9.8-based versions? (at least for now). Let me know if I have interpreted the email incorrectly. Thanks! Randy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr. Stephen Henson Sent: Wednesday, March 08, 2006 5:33 AM To: openssl-users@openssl.org Subject: Re: A little help would be appreicated On Wed, Mar 08, 2006, Stuart Halliday wrote: > > If it helps, here is how I generated the certs. > > 1st, the CA. > > openssl req -config openssl.cnf -new -x509 -keyout > ECS_CA/private/cakey.pem -out ECS_CA/cacert.pem -days 3650 > > > Then I used the following commands to generate the users certs on the Server: > > openssl req -new -key ECS_CA\private\cakey.pem -out stuarth.csr > openssl ca -policy policy_anything -out stuarth.cer -infiles stuarth.csr > > Infopath needs a cert with a private key so the .p12 format is required. > > openssl x509 -in stuarth.cer -out stuarth_certx509.pem > openssl pkcs12 -export -in stuarth_certx509.pem -inkey > ECS_CA\private\cakey.pem -out stuarth.p12 > > and it is stuarth.p12 which I import into mmc - Personal. > It looks like you are using the same key for the user certificates and the CA! Instead of manually entering commands use the CA.pl script instead. That is intended to just "do the right thing" when given some simple options. Don't use the CA.pl in the release version of 0.9.8 though: pick a recent snapshot or use 0.9.7. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [ANNOUNCE] OpenSSL version 0.9.8b and 0.9.7j released
Hi, Is there a brief on the reasons why someone would want to use OpenSSL 0.9.7j or choose to use 0.9.8b? I believe one of the items is that the 0.9.7 branch can be part of a solution for FIPS compliance, where 0.9.8b is "not there" yet. Is this correct? I'm at a point where I need to decide one release or the other, so I was curious if there was a pros and cons list or other way about going forward with 0.9.7j or 0.9.8b Thanks, Randy On May 4, 2006, at 7:57 AM, Dr. Stephen Henson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 0.9.8b and 0.9.7j released == OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 0.9.8b of our open source toolkit for SSL/TLS. This new OpenSSL version is a bugfix release and incorporates changes and bugfixes to the toolkit. For a complete list of changes, please see http://www.openssl.org/source/exp/CHANGES. We also release 0.9.7j, which contains several FIPS updates and bugfixes compared to 0.9.7i. It is the first full release of OpenSSL that can link against a validated FIPS module. These updates contain several bugfixes to resolve compilation issues under Win32 and errors in CA creation via the CA.pl script. We consider OpenSSL 0.9.8b to be the best version of OpenSSL available and we strongly recommend that users of older versions upgrade as soon as possible. OpenSSL 0.9.8b is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ For those who want or have to stay with the 0.9.7 series of OpenSSL, we strongly recommend that you upgrade to OpenSSL 0.9.7j as soon as possible. It's available in the same location as 0.9.8b. The distribution file names are: * openssl-0.9.8b.tar.gz MD5 checksum: 12cedbeb6813a0d7919dbf1f82134b86 SHA1 checksum: 99565db630a044fa484d4f91006a31908f262246 * openssl-0.9.7j.tar.gz MD5 checksum: 79dd939266b069e7aca587e6ab16a055 SHA1 checksum: 5277fa5a18d52fb0960e279fdbe198823f65da0b The checksums were calculated using the following commands: openssl md5 openssl-0.9.*.tar.gz openssl sha1 openssl-0.9.*.tar.gz Yours, The OpenSSL Project Team... Mark J. Cox Nils Larsch Ulf Möller Ralf S. Engelschall Ben Laurie Andy Polyakov Dr. Stephen Henson Richard Levitte Geoff Thorpe Lutz JänickeBodo Möller -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iQEVAwUBRFoRVqLSm3vylcdZAQIc/wf/axfaQgNC5PlXz6P21RbjkTDiRKaJETsc 3TPTVcOe1VN1j3Be3d+eb/PJLigGDQa3wI3Yci483O7y0XMzRHmb+KQakH0BAvIE 5Zkp9/lfm2MmAyaW4iZmSmQvSwE4sUcoveR+9v9zsHCvhduzi+9g3/ngsQzV9euI AmPptAfQJzp+AtKFfrOLTnYdNXGdhoKN+ItYCwqBsMrvew/8xKbCYwa29JtsM+Tm sBJK5/hhv3UO9TrNp3NDMNPf2Xvc3P/vVG1MRqw4F3hCoCieAhcxkhMKbKF/hnZY gMDXNYbtB/EY2G1IuoQ+9UbTaJEBs4wYjIWthlqQ5GaANtxYD8vmSQ== =Uzvl -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: renegotiating problem - connection hanging?
The discussion below wherein the term "you're screwed" is used seems to indicate that there is a deadlock situation, which isn't the case. There may or may not be performance issues associated with the scenario/use-case, but there's no deadlock. R -Original Message- From: [EMAIL PROTECTED] on behalf of David Schwartz Sent: Sat 6/10/2006 1:02 PM To: openssl-users@openssl.org Subject: RE: renegotiating problem - connection hanging? > Well, we are talking about s_client here... part of openssl executable. > select() is used with the blocking sockets to make sure that, well, they > don't block. It doesn't work that way. The only way to ensure that socket operations don't block is to set the sockets non-blocking. > If you call SSL_read on a blocking socket when select says > it is readable you expect it not to block [forever]. Of course > it might block > if there is some data available on the underlying socket but not > enough to > complete SSL deciphering, but under normal circumstances it will only > block until the rest of the record is received. Am I missing something? Here's a hypothetical. The 'select' function gives you a 'read' hit. You call SSL_read (thinking there's application-level data, but you don't really know, do you?). SSL_read reads part of a re-negotiation but has no data to return to you, so it calls 'read' again (how does it know it's not supposed to block until it has data?). That 'read' blocks forever because there was never any application-level data to read. Sorry, you're screwed. You are blocked in 'read' but the other side is waiting for you to send protocol-level data. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: CHecking the version of OpenSSL
I would probably consider the publishing of the openssl version on the web server announcment message as a security issue. Randy -Original Message- From: [EMAIL PROTECTED] on behalf of Marek Marcola Sent: Thu 8/10/2006 2:45 PM To: openssl-users@openssl.org Subject: Re: CHecking the version of OpenSSL Hello, > Does anyone know how to externally check what version of OpenSSL is > running a server? I mean without connecting to the server via the > shell but perhaps by a browser and checking the headers? If we are talking about HTTP servers then sometimes this information MAY be available in Server: tag. For example: $ telnet www.itrc.hp.com 80 Trying... Connected to itrc.hp.com. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.1 500 Internal Server Error Date: Thu, 10 Aug 2006 21:41:02 GMT Server: Apache/1.3.33 (Unix) mod_ssl/2.8.22 OpenSSL/0.9.7e <-- HERE Connection: close Content-Type: text/html; charset=iso-8859-1 Connection closed by foreign host. But ... this may be not available or may be not true if remote server administrator set value of this tag manually with some arbitrary string. Best regards, -- Marek Marcola <[EMAIL PROTECTED]> __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: CHecking the version of OpenSSL
Yes, nefarious types would eventually figure it out, but we probably shouldn't lay out the red carpet for them either...:) R. -Original Message- From: [EMAIL PROTECTED] on behalf of William A. Rowe, Jr. Sent: Thu 8/10/2006 3:44 PM To: openssl-users@openssl.org Subject: Re: CHecking the version of OpenSSL Randy Turner wrote: > I would probably consider the publishing of the openssl version on the web > server announcment message as a security issue. And some of us would laugh in your general direction ;-) Exploiters don't need to know, they can just persist till they find a known exploit. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Command-line file encryption
Using the following command... openssl enc -aes-256-cbc -salt -in -out I can create an AES-encrypted file. Subsequently I can use the -d option to decrypt the same file if I use the same key (when prompted) that I used to encrypt the file. I think the same initialization vector (IV) has to be used to decrypt the file as well. Is the decryption code mentioned above able to find the original IV used to encrypt the file somewhere in the encrypted file itself? How does it know this? Thanks! Randy __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Command-line file encryption
Ok, it looks like these values are computed from the password... Is the algorithm for computing the key and IV from the password published ? R. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Randy Turner Sent: Wednesday, August 23, 2006 1:40 PM To: openssl-users@openssl.org Subject: Command-line file encryption Using the following command... openssl enc -aes-256-cbc -salt -in -out I can create an AES-encrypted file. Subsequently I can use the -d option to decrypt the same file if I use the same key (when prompted) that I used to encrypt the file. I think the same initialization vector (IV) has to be used to decrypt the file as well. Is the decryption code mentioned above able to find the original IV used to encrypt the file somewhere in the encrypted file itself? How does it know this? Thanks! Randy __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Command-line file encryption
Thanks for the reply. So what you are saying is that if I encrypt a file with a password according to my interpretation of PKCS#5/PBKDF2, then it might not decrypt properly (with the same password) using the command-line openssl function? R. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marek Marcola Sent: Wednesday, August 23, 2006 11:53 PM To: openssl-users@openssl.org Subject: RE: Command-line file encryption Hello, > Ok, it looks like these values are computed from the password... > > Is the algorithm for computing the key and IV from the password > published ? PBKDF2 from PKCS#5 realized by EVP_BytesToKey() in OpenSSL. I don't remember exactly but there was some incompatibility with this standard ... Best regards, -- Marek Marcola <[EMAIL PROTECTED]> __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: build openSSL for an embedded system without an OS
Hi, I think there is probably a *formal* way to do this within the confines of the build system and design of OpenSSL, and there is probably a brute-force way to do this. I think just grabbing the crypto subtree and building a "make" subsystem for this that makes no dependencies on platform is one way to do this, which may involve source code changes, so you would need to re-integrate each release of openssl as it comes available. I anxiously await a response that works within the confines of the formal (and supported) build system, as I am interested as well... Randy On Feb 17, 2009, at 4:08 PM, Guyotte, Greg wrote: Hi – I am wondering if it is possible to build openSSL (or actually a very small portion of it) for use in an embedded ROM on an ARM11- based system. For my purpose I only need to be able to perform RSA public key decryption within the ROM. Being a ROM, I have no OS support whatsoever. I have compiled openssl using my cross compiler. The steps I used to accomplish that: a) ./Configure linux-elf --prefix=/db/nsel/db/avalanche/progs/mv2/ v6_le_uclibc --openssldir=/db/nsel/db/aval anche/progs/mv2/v6_le_uclibc/openssl no-asm no-shared b) make CC=arm_v6_le_uclibc-gcc "AR=arm_v6_le_uclibc-ar r" RANLIB=arm_v6_le_uclibc-ranlib Just for testing purposes, I put a dummy call to RSA_public_decrypt() in my ROM code, and linked with libcrypto.a. What results is a number of undefined symbols relating to OS-type calls (getpid, socket, etc…): Linking ... Error: L6218E: Undefined symbol stderr (referred from cryptlib.o). Error: L6218E: Undefined symbol getpid (referred from rand_unix.o). Error: L6218E: Undefined symbol open (referred from rand_unix.o). Error: L6218E: Undefined symbol fstat (referred from rand_unix.o). Error: L6218E: Undefined symbol close (referred from rand_unix.o). Error: L6218E: Undefined symbol getuid (referred from rand_unix.o). Error: L6218E: Undefined symbol poll (referred from rand_unix.o). Error: L6218E: Undefined symbol __errno_location (referred from rand_unix.o). Error: L6218E: Undefined symbol read (referred from rand_unix.o). Error: L6218E: Undefined symbol socket (referred from rand_egd.o). Error: L6218E: Undefined symbol connect (referred from rand_egd.o). Error: L6218E: Undefined symbol write (referred from rand_egd.o). Error: L6218E: Undefined symbol __ctype_b (referred from obj_dat.o). Error: L6218E: Undefined symbol fopen64 (referred from bss_file.o). Has anyone accomplished a similar task to what I am trying to do? I’m hoping that perhaps I made a mistake using the Configure script, and a different set of parameters will solve this problem. Thanks and regards, Greg Guyotte
FIPS vs. standard distribution
Hello List, I was curious about the diffs between the FIPS distribution of OpenSSL and the "standard" distribution. It seems like the FIPS tar file is based on an entirely different versioning system, but I'm assuming there is a table somewhere that maps this version back to a 0.9.x release version, but this is just a guess. I guess the basic question I have is this: If I have an application that utilizes OpenSSL 0.9.8j and all the functions seem to work fine, and then I realize I need a version of my application that will be undergoing FIPS certification, can I just rebuild my application, pointing at the FIPS openssl libraries or do the API calls into openssl change (like adding a "FIPS_" prefix in front of each normal openssl API call). Thanks! Randy __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
ASN.1 library
Hello list, Are the ASN.1 functions in OpenSSL "generic" enough to be used for other purposes besides reading/writing certificates? I was curious if the ASN.1 code could encode/decode both BER and DER, generically, even if the source of the data is NOT associated with certificates. For instance, can these routines be used to encode/ decode a CMS container. Since CMS is pretty close to PKCS#7, my assumption would be "yes". But taken to another extreme, could I use the ASN.1 library in OpenSSL to encode/decode Kerberos traffic, or SNMP traffic (BER), or other protocols encoded in BER/DER? Just curious how "reusable" the OpenSSL ASN.1 was, and if it's not "quite" as reusable as I am thinking about, is there a generic library available? I've tried using "asn1c", but this code seems to break when I feed it valid BER... Thanks! Randy smime.p7s Description: S/MIME cryptographic signature
Re: ASN.1 library
On Apr 2, 2009, at 2:22 PM, Dr. Stephen Henson wrote: On Thu, Apr 02, 2009, Randy Turner wrote: Hello list, Are the ASN.1 functions in OpenSSL "generic" enough to be used for other purposes besides reading/writing certificates? Yes. I was curious if the ASN.1 code could encode/decode both BER and DER, generically, even if the source of the data is NOT associated with certificates. For instance, can these routines be used to encode/ decode a CMS container. Since CMS is pretty close to PKCS#7, my assumption would be "yes". But taken to another extreme, could I use the ASN.1 library in OpenSSL to encode/decode Kerberos traffic, or SNMP traffic (BER), or other protocols encoded in BER/DER? Just curious how "reusable" the OpenSSL ASN.1 was, and if it's not "quite" as reusable as I am thinking about, is there a generic library available? I've tried using "asn1c", but this code seems to break when I feed it valid BER... OpenSSL supports CMS already. It should always decode BER correctly. DER is output in most cases. The one exception is streaming encode currently used for CMS and PKCS#7 in 1.0.0-beta and later only. The way that I interpret the above paragraph, I can use the OpenSSL ASN.1 code to decode BER and output DER. Can I "encode" BER and "decode" DER? Thanks! Randy Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ 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: Decrypting a password encrypted pkcs7-envelopedData
Just for my own edification, from this thread, it sounds like OpenSSL doesn't support password-protected PKCS#7 bundlesis this interpreation correct? Randy On Apr 29, 2009, at 6:16 AM, Dr. Stephen Henson wrote: On Wed, Apr 29, 2009, Mathieu Malaterre wrote: On Wed, Apr 29, 2009 at 12:14 PM, Dr. Stephen Henson > wrote: On Wed, Apr 29, 2009, Mathieu Malaterre wrote: That involves the use of a password based recipient info structure which OpenSSL doesn't currently support. Ah ! Thanks for the info. Doing some google search on the openssl mailing list it appears that PKCS5_PBKDF2_HMAC_SHA1 could be the function I am looking for ? Is this correct ? If this is the case I need to write something like: OpenSSL_add_all_algorithms(); EVP_PKEY *pkey = ??; // complex part data = BIO_new_mem_buf(array, len); // output of fread p7=d2i_PKCS7_bio(data,NULL)) p7bio=PKCS7_dataDecode(p7,pkey,NULL,NULL); What I am not clear is how do I create this EVP_PKEY from PKCS5_PBKDF2_HMAC_SHA1 function... Err no it's not a simple fix. You can't use PKCS#7 for a start because that format isn't compatible: you need the CMS routines. Then you'd need to implement appropriate handling of that recipient info type in the library. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ 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: relationship between FIPS module and OpenSSL
From this thread, it sounds like relying on the OpenSSL-FIPS canister for cryptography means you can't use hardware cryptographic accelerators through the engine interface, because the crypto would be done in h/w and NOT within the canister? I'm assuming if the h/w cryptographic module itself is FIPS-certified, and is accessed through the OpenSSL engine interface, then you could say this "solution" is FIPS certifiable. Randy On May 8, 2009, at 6:22 AM, Bill Colvin wrote: Try: export OPENSSL_FIPS=1 unset OPENSSL_FIPS Bill -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org ] On Behalf Of Carl Anderson Sent: May 8, 2009 8:39 AM To: openssl-users@openssl.org Subject: Re: relationship between FIPS module and OpenSSL I was using openssl to encrypt files at the command line and I was wondering if the FIPS mode could be enabled for doing that. Carl Anderson On Thu, May 7, 2009 at 6:26 PM, Kyle Hamilton wrote: OpenSSL FIPS is used essentially as a crypto engine, except that it's not called through the standard engine interface. The FIPS module is validated to perform its advertised functions; if it's in FIPS mode, OpenSSL will use its linked-in OpenSSL FIPS module to perform all of its cryptographic operations (and should be used in preference to engines, as well, since a FIPS operational environment requires all cryptographic operations to be performed within the bounds of a validated cryptographic canister). If the OpenSSL library is not in FIPS mode, then it's essentially ignored. -Kyle H On Thu, May 7, 2009 at 1:31 PM, wrote: Hi, Could someone please explain to me in simple terms the relationship between the OpenSSL FIPS module and OpenSSL itself? Is the FIPS module used by OpenSSL as a crypto engine or such like or am I way off base here? Thanks for any assistance or pointers. Thanks, Carl __ 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- us...@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 __ 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: 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: 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: 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
Re: pkcs12 command does not work in FIPS mode
That would imply that, when operating in FIPS mode, FIPS sites in the US Govt. can't import or export certificates. In the comment below, the phrase "Most browser output...". Is there any browser that uses FIPS algorithms to import/export certs? Randy On Jun 18, 2009, at 9:55 AM, Dr. Stephen Henson wrote: On Thu, Jun 18, 2009, Lior Aharoni wrote: Hello, I have encountered a problem when trying to use OpenSSL command to decode PKCS12 file, I am using OpenSSL 0.9.8j that was build with FIPS support enabled. When working in non FIPS mode I perform the following operation successfully: * K:\>openssl OpenSSL> pkcs12 -in k:\server.p12.pfx * When I am in FIPS mode and perform the same operation I get the following error: * Error outputting keys and certificates 7956:error:0607B090:digital envelope routines:EVP_CipherInit_ex:disabled for fips:.\crypto\evp\enc_min.c:306: 7956:error:06074078:digital envelope routines:EVP_PBE_CipherInit:keygen failure:.\crypto\evp\evp_pbe.c:101: 7956:error:23077073:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 algor cipherinit error:.\crypto\pkcs12\p12_decr.c:83: 7956:error:2306A075:PKCS12 routines:PKCS12_item_decrypt_d2i:pkcs12 pbe crypt error:.\crypto\pkcs12\p12_decr.c:123: error in pkcs12 * Can someone shed light on why this does not work in FIPS mode? How does this functionality contradict the FIPS requirements? Most browser output PKCS#12 files use 40 bit RC2 to encrypt certificates. That algorithm is not permitted in FIPS mode. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ 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: OCSP_basic_verify:root ca not trusted
Is the OCSP response verification algorithm described below implemented exclusively by OpenSSL, or is the algorithm an implementation of a particular RFC algorithm? Thanks! Randy On Jul 28, 2009, at 9:41 AM, Dr. Stephen Henson wrote: On Tue, Jul 28, 2009, Natanael Mignon - michael-wessel.de wrote: Dear list, another problem with the OCSP-handling in Apache/mod_ssl: [Tue Jul 28 14:27:12 2009] [error] SSL Library Error: error: 27069070:OCSP routines:OCSP_basic_verify:root ca not trusted [Tue Jul 28 14:27:12 2009] [error] failed to verify the OCSP response! Now, of course this could be just correct and there could be an error with the certificate store etc. But we get this error, when a client authenticates using certificate "b3", which is issued by "CA3" and the OCSP request is sent to "ocsp3". "CA3" is trusted for Apache and also present and symlinked in /etc/ssl/certs. If the client authenticates using cert "b2", which is issued by "CA2" and the responder is "ocsp2", everything is fine. "CA2" is trusted in the same way as "CA3". If the client authenticates using cert "b1", which is issued by "CA1" and the responder is "ocsp1", everything is fine. "CA1" is trusted in the same way as "CA2" and "CA3". To verify the OCSP handling, we execute the requests manually: openssl ocsp -issuer CA1 -serial -uri ocsp1... --> GOOD, verify OK. openssl ocsp -issuer CA2 -serial -uri ocsp2... --> GOOD, verify OK. openssl ocsp -issuer CA3 -serial -uri ocsp3... --> GOOD, verify FAIL. openssl ocsp -issuer CA1 -serial -uri ocsp3... --> GOOD, verify OK! So obviously the OCSP signer certificate of ocsp3 has been issued by CA1 (what we found in the OCSP response itself, of course). What we did not get straight so far: How is the issuer certificate determined to validate the OCSP signer certificate against in the library functions (i.e. when Apache calls the OCSP verify functions)? What might be needed here to get OpenSSL validate against the correct issuer certificate? I'm not sure what the problem is here. According to your description the responder ocsp3 is misconfigured and OpenSSL is behaving as you would expect. That error is due to the way OCSP responses are verified. It first tries to see if the response should be automatically accepted (responder certificate is issued by the CA or is the CA itself) if that fails it checks to see if the certificate is allowed to sign responses for *any* CA, so called "global responders". If thet fails you get the root CA not trusted meaning it isn't trusted as a global responder. 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 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
