Unique naming convention that can be used for certificates Reg.

2012-05-17 Thread Ashok C
Hi,

What would be the unique names with which I can store CA certificates in
file system?
I understand that issuer-id and serial number are the unique identifiers
for a certificate. But using this name for a certificate file name makes it
very long and also introduces some characters like @,= etc, which I
consider undesirable for file naming.
I considered using serial number, but one more thing I want to achieve is
that by looking at the file name I should be able to identify what
certificate it actually is. Eg: verisign-subca3.pem would mean that this is
the 3rd subordinate CA from verisign.
These certificates are copied to the filesystem by my application and I
need to generate these names from the certificates and also make sure that
each name is unique and does not clash in any way and also in compliance
with the UNIX file naming standards.

Regds,
Ashok


Openssl and config file options

2012-05-17 Thread kenc_openssl
Hi,

I am trying to add extra extensions to certain certificates that I 
sign with my own CA.

1) I'd like all server generated certificates to have:

basicConstraints = CA:false

and one of the certificates to have:

extendedKeyUsage = serverAuth

I created an extra section called new_section in my config file and 
tried to use the -extensions new_section with my openssl ca 
command, which worked but it did not read the basicConstraints = 
CA:false also (unless I explicitly added that to the new_section, 
and then it did).

Is there a way that I can / should be doing it so that my 
new_section only has the extra extensions that I wish to add to the 
certificate?

2) I am trying to generate a cert for OpenLDAP and I previously 
used the certtool command that read in from a config file. The 
extra options that I needed to add here are: tls_www_server, 
signing_key, encryption_key

What are the corresponding options that I need in my openssl config 
file? I think that tls_ww_server is extendedKeyUsage = serverAuth 
but I am not sure about this or the other two.

Thanks in advance for your help.

Ken


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number

2012-05-17 Thread Greg Wittmeyer
Hello all, hope someone can help.

I upgraded from 1.0.0d to 1.0.1c and immediately started getting this error:

error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number

It occurs during SMTP after successful negotiation.  Oddly, the first command 
after negotiation works, but not the second.  Here is the complete conversation:

220 mail.gammadyne.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.4675 
ready at  Wed, 16 May 2012 23:59:12 -0500
EHLO gammadyne.com
250-mail.gammadyne.com Hello [64.126.68.153]
250-AUTH=LOGIN
250-AUTH LOGIN
250-TURN
250-SIZE 3072
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-TLS
250-STARTTLS
250 OK
STARTTLS
220 2.0.0 SMTP server ready
SSL negotiated, cipher=DES-CBC3-SHA, bits=168, version=TLSv1/SSLv3
EHLO gammadyne.com
250-mail.gammadyne.com Hello [64.126.68.153]
250-AUTH=LOGIN
250-AUTH LOGIN
250-TURN
250-SIZE 3072
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250 OK
AUTH LOGIN
SSL read error 1: SSL module internal error
error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number


My configuration is as follows:

ctx = SSL_CTX_new(SSLv23_client_method());
SSL_CTX_set_mode(ctx, SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER | 
SSL_MODE_AUTO_RETRY);
SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, NULL);


I've tried the following solutions to no avail:
* Upgrading NASM to latest version
* Upgrading Perl to latest version
* Installing all updates on the mail server (Windows 2003/IIS6)
* SSL_OP_ALL, SSL_OP_CIPHER_SERVER_PREFERENCE, 
SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION

Using SSL_OP_NO_TLSv1 does fix the problem, but I don't really want to disable 
TLS1.

Could it be the cipher?  On 1.0.0d, the negotiated cipher was RC4-MD5

It's a rather odd problem.  Anyone have any ideas?

TIA, Greg Wittmeyer, Gammadyne Corp.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Cert order in .pem format

2012-05-17 Thread KThirumal
Team,

Had a query in the certs that we load,

The CA's provide our certs in .p12 format, which we need to convert to a 
.pem and load to SSL structure during initialization.
On converting to .pem, it is in the following format, Private Key, CA 
Certs and Domain Certificate.

In our code, we use the below snippet to load keys in in SSL structure,

1. err =  SSL_CTX_use_certificate_chain_file(ctx, KeyFile);
2. SSL_CTX_set_default_passwd_cb(ctx, passwd);
3. err = SSL_CTX_use_PrivateKey_file(ctx, KeyFile, SSL_FILETYPE_PEM);
4. SSL_CTX_check_private_key(ctx);

When i use the same order in the key ( Private Key, CA Certs and Domain 
Certificate ), the above fails in step 3. 
So we have to rearrange this order to Domain Certificate, Private Key and 
CA Certs for the above snippet to work properly.

We are trying to reduce the effort here, for someone to rearrange this 
cert order. 
Can you suggest some other way to convert the certs as expected by the 
code or change the order of our code.

Appreciate your help ..

Thanks  Regards

Karthikeyan Thirumal

**
This message and any files or attachments sent with this message contain 
confidential information and is intended only for the individual named.  If you 
are not the named addressee, you should not disseminate, distribute, copy or 
use any part of this email.  If you have received this message in error, please 
delete it and all copies from your system and notify the sender immediately by 
return Email.

Email transmission cannot be guaranteed to be secure or error-free as 
information can be intercepted, corrupted, lost, destroyed, late, incomplete or 
may contain viruses.  The sender, therefore, does not accept liability for any 
errors or omissions in the contents of this message, which arise as a result of 
email transmission.
**