Re: [error] Certificate Verification: Error (34): unhandled critical extension
Bonjour Peter Sylvester, >>Extensions are ignored in the root. >>Without telling what critical extensions you have, it is difficult to help. I had some extensions set to critical in my Sub CA certificates, i have re generated all the sub CA certificates and now it works fine. Thats rite that critical extension are only ignored in root, if Sub CA's contain some critical extensions apache mutual authentication fails. Thanks so much for the guidance ... Best Regards Scott Thomas
RE: openssl 1.0.0 issue with sendmail
> From: owner-openssl-us...@openssl.org On Behalf Of David Carvalho > Sent: Wednesday, 09 June, 2010 06:06 > I am having trouble since I replaced my e-mail server (hardware and to Fedora 12). > Basically I'm using almost the same sendmail.mc file than in the previous server > (running openssl 0.9.6, I think). > The problem is that Windows XP clients running Outlook, outlook express or windows mail can not > relay, as they fail to STARTTLS. ... > In my previous server logs, I saw that the windows XP clients used RC4-MD5 cipher, but now > I get >STARTTLS=server, error: accept failed=-1, SSL_error=5, errno=104, retry=-1 5 is SSL_ERROR_SYSCALL -- an I/O operation (likely recv()) failed with that errno. On one Linux I have to hand 104 is ECONNRESET; I'm not sure it's the same on (all) others but that's certainly a likely I/O error on a socket. If so, either the client is failing or something in between like maybe a firewall is breaking your connection. There may be helpful log information on the client; see below. Or a net monitor like your ssldump below will show *when* in the protocol the problem occurred. (Normally I would also suggest s_server, but it doesn't do STARTTLS.) and other times STARTTLS=server, error: accept failed=-1, SSL_error=1, errno=0, retry=-1 depending on wich client. 1 is SSL_ERROR_SSL which is either an actual error in the protocol or an error reflected through the protocol i.e. a fatal alert; errno is (usually) meaningless and the program should call SSL_print_errors[_fp] or similar logic to get useful info. If it is not doing so and you can't get it to (maybe some option, I don't know sendmail) monitor as above. > I've found some information confirming this issue with older Windows at > http://www.skytale.net/blog/archives/22-SSL-cipher-settings.html See below. > From: owner-openssl-us...@openssl.org On Behalf Of David Carvalho > Sent: Wednesday, 09 June, 2010 07:37 > Subject: openssl 1.0.0 issue with sendmail (ssldump output) > After installing ssldump, I could compare windows xp and windows 7 clients STARTTLS negotiation. > While the windows 7 used TLS_RSA_WITH_AES_128_CBC_SHA via TLSv1/SSLv3 > Windows XP output is > New TCP connection #1: 10.0.0.252(5000) <-> my.server (25) > 1 1 0.0182 (0.0182) C>S SSLv2 compatible client hello > Version 3.1 > cipher suites > 1 2 0.0188 (0.0005) S>C Handshake > ServerHello > Version 3.1 > session_id[32]= > cipherSuite TLS_RSA_WITH_RC4_128_MD5 > compressionMethod NULL > 1 3 0.0188 (0.) S>C Handshake > Certificate > 1 4 0.0202 (0.0014) S>C Handshake1 5 0.0202 (0.) S>C Handshake10.0229 (0.0026) C>S TCP FIN > 10.0230 (0.0001) S>C TCP FIN Did you delete or suppress some details? After ServerHello server should send Certificate (partly shown), ServerKeyExchange and ServerHelloDone (not show). (Also CertRequest if you use client authentication aka client certs, but it doesn't look you do and you certainy didn't say so.) At that point this client apparently just closes the connection (C>S FIN then S>C FIN) which is abnormal. Probably only the client can tell you why it did this. Also, this doesn't show any STARTTLS; I don't know if ssldump doesn't show pre-SSL traffic on a connection, or you suppressed it, or what. > New TCP connection #2: 10.0.0.252(1025) <-> my.server(25) > 260.0266 (60.0266) C>S TCP FIN > 260.0267 (0.) S>C TCP FIN This is really strange -- it connects and then does nothing for 60 seconds? Either your monitor is missing some traffic, or this client is weird. > So how can I enable SSLv2 support ? Is it on openssl or sendmail ? You shouldn't want or need SSLv2 *protocol*; it's obsolete and unsafe. As the website you referenced explicitly says. The client in this case is offering to negotiate up to 3.1 (which is TLS1.0). Don't be fooled by the 'SSLv2 *compatible* hello'; that doesn't mean it wants v2. The old *ciphersuites* are still available in SSL3/TLS unless you disable them; the discussion on that website about !SSLv2 in the cipherstring is exactly that. In this case the server agreed to an RC4-MD5 suite, as you say the XP clients previously liked. I think only the client can say what's going on here; see below. A thought: is the new server using the same (keypair&)cert as the old one? If not, does the client need to be told to trust the new one? I'd guess that Outlook etc. would use the same truststore as IE, but that's only a guess. But if anything I would expect newer Windows' apps to be *more* strict here not less; IE7 certainly is. Googling found http://www.mofeel.net/448-comp-mail-sendmail/3469.aspx
certs with the same Subject Name
I have 2 different certs with the same subject name in a CA dir: lrwxrwxrwx 1 chris chris 23 2010-06-10 14:35 0721e1e6.0 -> other.pem lrwxrwxrwx 1 chris chris 18 2010-06-10 14:35 0721e1e6.1 -> ssl.pem when I try to establish an ssl connection: openssl s_client -verify 10 -connect example.com:443 -CApath same_names I get: Verify return code: 18 (self signed certificate) it appears to be choosing 0721e1e6.0, because if I delete that one, it works. Since there is no requirement that Subject Names be unique, is there a way to make this work? -- Chris Bare ch...@bareflix.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Segfault when encrypting
Hannes Schuller wrote: > > I'm very puzzled here. Why do you sign the reply and then sign a hash > > of the signature? You say "Message encryption successful", but that's > > a signature you're doing, not an encryption. > I was under the impression that RSA_private_encrypt and > RSA_public_encrypt do nothing but encrypt the given payload. The > (non-quoted) code before this ensures the reply is shorter than the > regular message digest length. RSA is a low-level algorithm. It provides primitives called "encryption" and "decryption". But whether they actually encrypt (in the sense of concealing contents so that only a desired party can access them) depends on the system as a whole. So yes, RSA_private_encrypt performs the RSA primitive operation known as "encryption". But it doesn't actually encrypt anything in the sense of concealing contents to that only a desired party can access them. (Because anyone with the public key can reverse the operation.) > What would be the prefered way for encryption? See the various EVP_Encrypt functions that provide encryption in the conventional sense rather than the RSA_* functions that provide RSA primitive operations that may or may not meet security objectives. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: is openssl library thread safe
See http://lmgtfy.com/?q=openssl+thread+safe From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Arunkumar Manickam Sent: Thursday, June 10, 2010 8:18 AM To: openssl-users@openssl.org; openssl-...@openssl.org Subject: is openssl library thread safe Hi, Is openssl library thread safe so that it can be used in an multithreaded environment as is. Thanks, Arun
Header file confliction for Openssl 1.0 and winsock2.h
Winsock.h file is included in dtls1.h, and also dtls1.h included in ssl.h, without any conditions. This will make the project which use Windows socket and openssl get a lot of compiling errors. Nowadays most people on Windows use winsock2.h instead of winsock.h, by defining WIN32_MEAN_AND_LEAN, etc. At least OpenSSL should check all those pre-definitions to decide whether winsock.h or winsock2.h to be included or even none. Kevin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Segfault when encrypting
"David Schwartz" wrote:
>
> Hannes Schuller wrote:
>
> > hash = (unsigned char *)malloc(RSA_size(rsa) * sizeof(unsigned
> > char)); ciphertext = (char *)malloc(RSA_size(rsa) * sizeof(char));
> > signature = (char *)malloc(RSA_size(rsa) * sizeof(char));
> > if (ciphertext != NULL && signature != NULL && hash != NULL) {
> > memset(ciphertext, 0, RSA_size(rsa));
> > ok = RSA_private_encrypt(strlen(reply), (unsigned char
> > *)reply, (unsigned char *)ciphertext, rsa, RSA_PKCS1_PADDING);
> > if (ok < 0) {
> > derror1("Message encryption error: %s",
> > ERR_error_string(ERR_get_error(), (char
> > *)NULL)); return (true);
> > } else {
> > dtrace1("Message encryption successful; return
> > value: %d", ok); }
> > len = base64Encode(ciphertext, ok);
> > memset(hash, 0, RSA_size(rsa));
> > RIPEMD160((unsigned char *)ciphertext, len, hash);
> > memset(signature, 0, RSA_size(rsa));
> > ok = RSA_private_encrypt(RIPEMD160_DIGEST_LENGTH, hash,
> > (unsigned char *)signature, rsa, RSA_PKCS1_PADDING);
>
> I'm very puzzled here. Why do you sign the reply and then sign a hash
> of the signature? You say "Message encryption successful", but that's
> a signature you're doing, not an encryption.
I was under the impression that RSA_private_encrypt and
RSA_public_encrypt do nothing but encrypt the given payload. The
(non-quoted) code before this ensures the reply is shorter than the
regular message digest length.
What would be the prefered way for encryption?
> > That final line causes a segmentation fault. Here is a backtrace:
> >
> > -
> > #0 0x774d0ba6 in ?? () from /lib/libc.so.6
> > #1 0x774d2aa0 in malloc () from /lib/libc.so.6
> > #2 0x77abc962 in CRYPTO_malloc (num=-142946720,
>
> Since the fault is in 'malloc', that indicates something is trashing
> the heap. Tools like 'valgrind' can find this for you. My guess would
> be that the problem lies in 'base64Encode'. It doesn't seem to have
> any place to put its output (and if it operates in place, it may
> overflow the memory allocated for 'ciphertext'), but for all I know
> it calls 'realloc' internally.
Good point, I'll investigate.
> I have to also give you a generic warning -- there are some subtle
> clues in your code that suggest that you do not know what you're
> doing. If you, or anyone else, is going to rely on this code to meet
> any security requirements, I *strongly* urge you to have the code
> evaluated by a security expert sooner rather than later. It appears
> that you have designed this code such that only the public key is
> needed to perform an operation that you think of as decryption, and
> that's usually a sign of a serious design flaw.
I'm aware this is not the way it is intended and that it will only have
any security effect as far as signing the payload is concerned. Don't
worry. It's a long (boring) story.
Hannes
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: is openssl library thread safe
Hi, Thus wrote Arunkumar Manickam (arun.c...@gmail.com): > Is openssl library thread safe so that it can be used in an multithreaded > environment as is. http://www.openssl.org/support/faq.html#PROG1 Regards, Martin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Preamble Change with PKCS12 -> PEM
On Wed, Jun 09, 2010, Robinson, Richard L (Rick) wrote: > I was evaluating openssl-1.0.0a and performed a PKCS12 conversion to PEM > using the following command: > > openssl pkcs12 -in myfile.p12 -nodes -out myfile.pem > > However, I noticed that in the resulting PEM file the preamble for the > resulting private key displayed "-BEGIN PRIVATE KEY-" > > If I performed the same command using openssl-0.9.8k, the preamble for > the private key is displayed as "-BEGIN RSA PRIVATE KEY-" (which > is consistent with prior versions of openssl). > > I also noticed that the extracted private key is different when I use > 1.0.0a. It is smaller but the certificate extracted from the p12 file is > the same for both versions of openssl. > > I believe this may be due to a FIPS flag, but I cannot confirm that in > reviewing the config files or code (but it may be there). > > Does anybody know why the premable and private key is different when I > use 1.0.0a (it is causing me some import problems of the private key > with other software)? > OpenSSL 0.9.8 used what I've called the "traditional" private key format which was unchanged since SSLeay, non-standard, no private key iteration count and using the deprecated MD5 algorithm. FIPS mode in 0.9.8 (where MD5 use is illegal) and 1.0.0 in general now uses PKCS#8 format. 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: is openssl library thread safe
Hi, Yes, it is thread safe if you define and initialize necessary locking functions at startup: http://www.openssl.org/docs/crypto/threads.html Regards, AW Arunkumar Manickam pisze: Hi, Is openssl library thread safe so that it can be used in an multithreaded environment as is. Thanks, Arun __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: compilation problem for xscale.
My apologies to all for mis-remembering what package the issue was relating to - it was with an iscsi target (IET, which is certainly GPL!). I was working with both openssl and IET when I had this problem, and for some reason I associated it with openssl instead of IET. Sorry for the extra noise! (Since I mis-remembered the kernel module that I was having trouble with, unless someone wants to discuss the issues of cross-compiling kernels (and executables) and getting GPL-only symbol exporting to work, I expect this is my last posting here on this subject unless others wish to discuss cross-compiling and EXPORT_SYMBOL_GPL here). If anyone cares to know what actually is the story: IET (iSCSI Enterprise Target) uses the crypto interface. I am cross-compiling to arm/xscale - the kernel using the 'arm-2006q3' toolchain, and executables and modules using the 'armv5l-linux' toolchain. But the resulting ietd fails to load because it cannot 'find' the crypto symbols. (If I change the export to non-GPL and rebuild the kernel, ietd loads fine, so it's a "cannot resolve symbol" issue, not a binary incompatibility issue). After some fooling around, my current theory that my problem is related to the fact that this is a cross-compiled kernel. I grepped every single file in my kernel build tree, and no non-source file anywhere has 'crypto_register_alg' inside it. And I don't see ANY of the other crypto GPL symbols in the symbol table! (System.map) So, I'm trying to find anyone who has cross-compiled a kernel for xscale and been able to load GPL kernel modules which used the GPL kernel symbols. Or, put another way - I want to find out if KERNEL_EXPORT_SYMBOL_GPL works under a cross-compile environment. (I am using 'arm-2006q3' toolchain) The first part of my initial email follows, but changed to fit reality. Thanks! Rusty (the original poster) -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Carruth, Rusty Sent: Friday, May 21, 2010 10:43 AM To: openssl-users@openssl.org Subject: compilation problem for xscale. I've compiled a GPL module (IET) to run on an xscale, and it worked fine except for one major issue - I could not load the __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
is openssl library thread safe
Hi, Is openssl library thread safe so that it can be used in an multithreaded environment as is. Thanks, Arun
