How to get buffer size after calling PEM_write_bio_PrivateKey

[Peter Lin]

Hi all,

I need to know how many of bytes have been written after calling
PEM_write_bio_PrivateKey.

My code:
  BIO *bo = BIO_new( BIO_s_mem() );
  PEM_write_bio_PrivateKey(bo, key, 0, 0, 0, 0, 0);
Is there any way I can tell the size of memory written?

thanks
Peter Lin

How to get buffer size after calling PEM_write_bio_PrivateKey

[Peter Lin]

Hi all,

I need to know how many of bytes have been written after calling 
PEM_write_bio_PrivateKey.


My code:
  BIO *bo = BIO_new( BIO_s_mem() );
  PEM_write_bio_PrivateKey(bo, key, 0, 0, 0, 0, 0);
Is there any way I can tell the size of memory written?

thanks
Peter

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

EVP_Cipher()

[Xu, Qiang (FXSGSC)]

Hi, all:

It is understood that EVP_Cipher() is used in libssh2, but I am not sure from 
which release of openssl this function is introduced. Can anybody tell me this 
information?

By the way, how to check the version of openssl in my linux box? If it is not a 
version that has the definition of EVP_Cipher(), I may need to upgrade.

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

random crash in getrn function (ssl, crypto).

[Dan Ribe]

Hi Everyone,

I am using gsoap stub code on Mac & facing below mentioned crash
randomly. It seems that crash happens only if some error occurs in
tcp_connect & while getting error value.

Any pointers on this ? What may be causing this behavior ?

Crash stack:

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libcrypto.0.9.7.dylib   0x001d5cb8 getrn + 76
1   libcrypto.0.9.7.dylib   0x001d5c02 lh_insert + 285
2   libcrypto.0.9.7.dylib   0x0021f87d int_thread_set_item + 107
3   libcrypto.0.9.7.dylib   0x0021fbfd ERR_get_state + 207
4   libcrypto.0.9.7.dylib   0x0021fdb5 get_error_values + 33
5   libcrypto.0.9.7.dylib   0x0022003d ERR_peek_error + 40
6   libssl.0.9.7.dylib  0x001b4dd6 SSL_get_error + 25
7   clients.macintosh.MyApp  0x0002c959 tcp_connect + 3387
8   clients.macintosh.MyApp  0x0002b6bb soap_connect_command + 343
9   clients.macintosh.MyApp  0x0002b82f soap_connect + 39
10  clients.macintosh.MyApp  0x0007d4e7
soap_call___Version__GetClientVersion(soap*, char const*, char const*,
_Version__GetClientVersion*, _Version__GetClientVersionResponse*) + 243


Thanks for the help !

Cheers !

RE: Issue with SSL sockets & pthreads

[David Schwartz]

Laura Arhire wrote:

> if (pthread_create (&thr, NULL, print_message_function, (void *)
> &data) != 0)
> printf("Warning, create did not work for thread #%d\n",
> i);fflush(stdout);
> else
> {
> Sleep(1000);
> ClientSocket *client = SocketFactory::new_client_socket(SSL,
> (char *) "127.0.0.1", TEST_PORT);
>
> if (client->connect())
>client->disconnect();
>
> delete client;
>
> socket->shutdown();
> pthread_join(thr, NULL);
> }
>
> delete socket;
> }
>
> }

Well, this code extract is obvious nonsense. The 'else' statement cannot
attach to an 'fflush(stdout);' statement. If this is your actual code, it's
surprising it compiled.

When you get errors creating threads, the most common cause is that you
created threads and failed to either detach or join them (you must do one or
the other or you will leak threads). It's possible that your entire 'else'
block is not even running.

DS


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

[ANNOUNCE] OpenSSL.NET version 0.4 released

[Frank Laub]

OpenSSL.NET - Managed wrapper for the OpenSSL toolkit
http://openssl-net.sourceforge.net

I've pleased to announce the release of version 0.4 of OpenSSL.NET.

Description:
A managed OpenSSL wrapper written in C# for the 2.0 .NET Framework  
that exposes both the Crypto API and the SSL API. This a must for .NET  
developers that need crypto but don't want to use Microsoft's SSPI.  
This wrapper is based on version 0.9.8k of libeay32.dll and  
ssleay32.dll.


You can download a pre-built binary for win32 using the following link:
http://sourceforge.net/projects/openssl-net/files/openssl-net/0.4/openssl.net-0.4-win32.zip/download

In addition, source code is available via git under the New BSD License:
git://openssl-net.git.sourceforge.net/gitroot/openssl-net/openssl-net

Preliminary support for mono has been added and has been tested on  
debian x64 and Mac OS X 10.5.


A big thanks goes out to Ben Henderson for contributing the wrapper  
for the SSL library.


Enjoy,

-Frank

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

Re: How do I create TLS v1.0 Self Signed Certificates

[Dr. Stephen Henson]

On Wed, Sep 02, 2009, Kyle Safford wrote:

>  
> 
> I have been trying to determine if there is a specific command I need to
> use when creating Self Signed Certificates with openssl that determines
> TLS v1.0 over SSL v3.0?
> 

No there are no certificate fields or extensions that indicate TLS v1.0 as
opposed to SSL v3.0. This is determined by the server/client configuration
which uses the highest version common to both sides, so if both support TLS
v1.0 it will be used. 

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

How do I create TLS v1.0 Self Signed Certificates

[Kyle Safford]

Hi everyone,

 

I have been trying to determine if there is a specific command I need to
use when creating Self Signed Certificates with openssl that determines
TLS v1.0 over SSL v3.0? I have been using the following commands:

 

Create a file named openca.cnf and copy the content in italic into the
empty file. 
[ req ]
default_bits = 1024 # Size of keys 
default_keyfile = openca_key.pem # name of generated keys 
default_md = sha1 # message digest algorithm 
string_mask = nombstr # permitted characters. Any string.
distinguished_name = req_distinguished_name 
 
[ req_distinguished_name ]
# Variable name   Prompt string 
#--   -
0.organizationName = Org. Name
organizationalUnitName = Org. Name
emailAddress = ValidEmailAddress
emailAddress_max = 40 
localityName = City
stateOrProvinceName = State
countryName = US
countryName_min = 2 
countryName_max = 2 
commonName = ServerName
commonName_max = 64 
 
[ v3_ca ]
basicConstraints = critical,CA:TRUE #critical is important.
subjectKeyIdentifier = hash 
authorityKeyIdentifier = keyid:always,issuer:always
 
Run the following command:
openssl req -new -x509 -newkey rsa:1024 -extensions v3_ca -keyout
openca_key.pem -out openca_crt.pem -days 365 -config ./openca.cnf



Create a configure file (opencsr.cnf) which will be used by openssl to
generate CSR and private key.
[ req ]
default_bits = 512 # Size of keys. If server has domestic license, use
1024.
default_keyfile = opencert_key.pem # name of generated keys 
default_md = sha1 # message digest algorithm 
string_mask = nombstr # permitted characters 
distinguished_name = req_distinguished_name 
req_extensions = v3_req
 
[ req_distinguished_name ]
# Variable name   Prompt string 
#--   -
0.organizationName = Org. Name
organizationalUnitName = Org. Name
emailAddress = ValidEmailAddress 
emailAddress_max = 40 
localityName = City
stateOrProvinceName = State
countryName = US
countryName_min = 2 
countryName_max = 2 
commonName = ServerIP
commonName_max = 64 
 
[ v3_ca ]
basicConstraints = critical,CA:TRUE 
subjectKeyIdentifier = hash 
authorityKeyIdentifier = keyid:always,issuer:always
 
[ v3_req ] 
basicConstraints = CA:FALSE 
subjectKeyIdentifier = hash



   In dos command window, execute the following command:
   openssl req -new -nodes -out opencert_req.pem -config ./opencsr.cnf
 
   Execute the following command to sign the certificates:
openssl x509 -sha1 -req -days 365 -CAcreateserial -CA openca_crt.pem
-CAkey openca_key.pem -in opencert_req.pem -out opencert_crt.pem
 
Then I move the openca_crt.pem, opencert_crt.pem and opencert_key.pem
over to the Weblogic directories, load them into the cacerts directory
and Weblogic app. When I start Weblogic, it states that the SSL started
on the correct port without errors. I have enabled the TLSv1 option in
Internet Explorer and the Weblogic JAVAOPTIONS
(-Dweblogic.security.SSL.protocolVersion=TLS1). However, when I go to
the https://:/ I get a page display error. This only
is happening because we have the Windows Group Policy for "System
cryptography: Use FIPS compliant algorithms for the encryption, hashing,
and signing" Enabled. This policy limits us to the
TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite (only TLSv1.0 certificates
are valid). So the question comes back to, how do I specify TLSv1.0 for
the certificate when creating it over SSLv3.0?
 
Any help would be much appreciated.

 

Thank you in advance,

Kyle

 

---

Kyle Safford, Consultant

CGI Federal

838-B, 12601, Fair Lakes Circle

Fairfax, VA 22033

Office: 703 227 5592

kyle.saff...@cgifederal.com   

http://www.cgi.com  

---

 

Re: Memory leak in threaded server

[Robin Seggelmann]

I was able to solve the problem, the session cache was activated and  
stored all the sessions and a bug in DTLS caused that twice as much  
sessions as necessary have been created. The bug will be fixed with an  
updated version of bugfix #2028.


- Robin


Am 02.09.2009 um 10:47 schrieb Robin Seggelmann:


Hi all,
I have written an DTLS echo server and client for testing purposes.  
In this case I want to test my new DTLSv1_listen() function, which  
waits for new connections with responding to ClientHellos with  
HelloVerifyRequest messages until a ClientHello with a valid cookie  
arrives. The SSL object can then be used for that connection and  
DTLSv1_listen() is called with a new SSL object again. Unfortunately  
the server has a memory leak which I was unable to find yet.  
According to my debug tools the problem seems to be that some  
certificates aren't freed. However, there are no leaks in terms of  
memory that is not accessible anymore. Here is the scheme of my  
server:


void start_server(int port, in_addr_t* local_address) {

... (variables) ...

THREAD_setup();
OpenSSL_add_ssl_algorithms();
SSL_load_error_strings();
ctx = SSL_CTX_new(DTLSv1_server_method());
SSL_CTX_set_cipher_list(ctx, "ALL:NULL:eNULL:aNULL");
pid = getpid();
if( !SSL_CTX_set_session_id_context(ctx, (void*)&pid, sizeof pid) )
perror("SSL_CTX_set_session_id_context");

	if (!SSL_CTX_use_certificate_file(ctx, "certs/server-cert.pem",  
SSL_FILETYPE_PEM))

printf("\nERROR: no certificate found!");

	if (!SSL_CTX_use_PrivateKey_file(ctx, "certs/server-key.pem",  
SSL_FILETYPE_PEM))

printf("\nERROR: no private key found!");

if (!SSL_CTX_check_private_key (ctx))
printf("\nERROR: invalid private key!");

/* Client has to authenticate */
	SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | SSL_VERIFY_CLIENT_ONCE,  
dtls_verify_callback);


SSL_CTX_set_read_ahead(ctx, 1);
SSL_CTX_set_cookie_generate_cb(ctx, generate_cookie);
SSL_CTX_set_cookie_verify_cb(ctx, verify_cookie);

... (create listening socket) ...

while (1) {
memset(&client_addr, 0, sizeof(struct sockaddr));

/* Create BIO */
bio = BIO_new_dgram(fd, BIO_NOCLOSE);

/* Set and activate timeouts */
timeout.tv_sec = 5;
timeout.tv_usec = 0;
BIO_ctrl(bio, BIO_CTRL_DGRAM_SET_RECV_TIMEOUT, 0, &timeout);

ssl = SSL_new(ctx);

SSL_set_bio(ssl, bio, bio);
SSL_set_options(ssl, SSL_OP_COOKIE_EXCHANGE);

while (!DTLSv1_listen(ssl, &client_addr));

info = (struct pass_info*) malloc (sizeof(struct pass_info));
memcpy(&info->server_addr, &server_addr, sizeof(struct 
sockaddr));
memcpy(&info->client_addr, &client_addr, sizeof(struct 
sockaddr));
info->ssl = ssl;

if (pthread_create( &tid, NULL, connection_handle, info) != 0) {
perror("pthread_create");
exit(1);
}
ERR_remove_state(0);
}

THREAD_cleanup();
}


The function connection_handle is called when DTLSv1_listen()  
returned and therefore a new connection is about to be established.  
The SSL object is passed and the handshake finished before data  
transmission begins.


void* connection_handle(void *info) {

... (variables) ...

pthread_detach(pthread_self());

... (created connected socket) ...

/* Set new fd and set BIO to connected */
BIO_set_fd(SSL_get_rbio(ssl), fd, BIO_NOCLOSE);
	BIO_ctrl(SSL_get_rbio(ssl), BIO_CTRL_DGRAM_SET_CONNECTED, 0,  
client_addr);


/* Finish handshake */
if(SSL_accept(ssl) <= 0) {
perror("SSL_accept");
goto cleanup;
}

... (read and write until client disconnects) ...

SSL_shutdown(ssl);

cleanup:
close(fd);
free(info);
SSL_free(ssl);
ERR_remove_state(0);
pthread_exit( (void *) NULL );
}

Any suggestions where I forgot any free or threading function? I  
also read about a built-in memory leak detection in OpenSSL but  
didn't find anything in the documentation. Since it might help, how  
do I use that? When I use a shell script which continously starts a  
client which connects, sends some messages and disconnects, the  
server is working fine but constantly allocats memory which is never  
freed. Since the client initiates the shutdown, there is no problem  
with an unfinished shutdown process. The server's SSL_shutdown()  
always returns 1.


Regards,
Robin
__
OpenSSL Project htt

Re: ErrorCode 06065064

[Nigel Sollars]

Thank you very much,

Regards
Nigel


Dr. Stephen Henson wrote:

Comments inline:

On Wed, Sep 02, 2009, Nigel Sollars wrote:

  

Hi,

After looking at other examples, decided to go back to basic tried a simple 
approach at taking a string argv and passing that to the enc/dec methods,  
Seems i have the same errorcode as before.  I have provided the testfile 
any help with this one would be very much appreciated.






  

unsigned char *iv[8];
unsigned char  *password[16];



Definitions of iv, password are wrong. Get rid of the '*'.

  

string = argv[1];

RAND_bytes(iv, 8);
RAND_bytes(password, 16);

printf("Entering Encryption Stage:\n\n");
printf("String to encrypt: %s\n\n", string);

EVP_CIPHER_CTX_init(&ectx);


EVP_EncryptInit(&ectx, EVP_bf_cbc(), password, iv);

bzero (&enc_inbuf, input_buf_size);

if(!EVP_EncryptUpdate(&ectx, enc_outbuf, &encoutlen, string, 
strlen(string)))
{
printf("Error whilst EncryptUpdate\n");
return 0;
}

if(!EVP_EncryptFinal(&ectx, enc_outbuf + encoutlen, &enctotallen))
{
printf("Error Whilst EncryptFinal\n");
return 0;
}

encoutlen += enctotallen;




OK, you've got the total length of the encrypted data as "encoutlen" at this
point.

  

printf("Encryption Successful\n\n");
printf("Entering Decryption Stage\n\n");

EVP_CIPHER_CTX_init(&dctx);
EVP_DecryptInit(&dctx, EVP_bf_cbc(), password, iv);

bzero (&dec_inbuf, output_buf_size);
bzero (&dec_outbuf, input_buf_size);

if (!(EVP_DecryptUpdate(&dctx, dec_outbuf, &decoutlen, enc_outbuf, 
output_buf_size)))
{
printf("Error Whilst DecryptUpdate\n");
return 0;
}




But above you are passing the length as output_buf_size.

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

Re: ErrorCode 06065064

[Dr. Stephen Henson]

Comments inline:

On Wed, Sep 02, 2009, Nigel Sollars wrote:

> Hi,
>
> After looking at other examples, decided to go back to basic tried a simple 
> approach at taking a string argv and passing that to the enc/dec methods,  
> Seems i have the same errorcode as before.  I have provided the testfile 
> any help with this one would be very much appreciated.
>


> 
>   unsigned char *iv[8];
>   unsigned char  *password[16];

Definitions of iv, password are wrong. Get rid of the '*'.

>   string = argv[1];
> 
>   RAND_bytes(iv, 8);
>   RAND_bytes(password, 16);
> 
>   printf("Entering Encryption Stage:\n\n");
>   printf("String to encrypt: %s\n\n", string);
> 
>   EVP_CIPHER_CTX_init(&ectx);
> 
> 
>   EVP_EncryptInit(&ectx, EVP_bf_cbc(), password, iv);
> 
>   bzero (&enc_inbuf, input_buf_size);
> 
>   if(!EVP_EncryptUpdate(&ectx, enc_outbuf, &encoutlen, string, 
> strlen(string)))
>   {
>   printf("Error whilst EncryptUpdate\n");
>   return 0;
>   }
> 
>   if(!EVP_EncryptFinal(&ectx, enc_outbuf + encoutlen, &enctotallen))
>   {
>   printf("Error Whilst EncryptFinal\n");
>   return 0;
>   }
> 
>   encoutlen += enctotallen;
> 

OK, you've got the total length of the encrypted data as "encoutlen" at this
point.

>   printf("Encryption Successful\n\n");
>   printf("Entering Decryption Stage\n\n");
> 
>   EVP_CIPHER_CTX_init(&dctx);
>   EVP_DecryptInit(&dctx, EVP_bf_cbc(), password, iv);
> 
>   bzero (&dec_inbuf, output_buf_size);
>   bzero (&dec_outbuf, input_buf_size);
> 
>   if (!(EVP_DecryptUpdate(&dctx, dec_outbuf, &decoutlen, enc_outbuf, 
> output_buf_size)))
>   {
>   printf("Error Whilst DecryptUpdate\n");
>   return 0;
>   }
> 

But above you are passing the length as output_buf_size.

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: ErrorCode 06065064

[Nigel Sollars]

Hi,

After looking at other examples, decided to go back to basic tried a 
simple approach at taking a string argv and passing that to the enc/dec 
methods,  Seems i have the same errorcode as before.  I have provided 
the testfile any help with this one would be very much appreciated.


Regards

Nigel Sollars wrote:

Hi all,

After looking at many examples and reading the OpenSSL book i 
purchased, I was wondering what the usual culprits are for the 
errorcode 06065064.  By the looks of it, it could be a bad password / 
key or perhaps a wrong sized outbuf.



Any more information would be highly appreciated,

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



/*
 *  file test1.c
 *
 *  simple round robin test to take 2 inputs, a key & a string to encrypt
 *  Encrypt the string then decrypt priinting out status as we go.
 *
 *  Use the supplied Makefile to build
 *
 */

#include 
#include 
#include 
#include 
#include 

#define input_buf_size 1024
#define output_buf_size 1032

int main(int argc, char *argv[])
{

if (argc !=2)
{
printf("Usage: test1 \n");
exit(1);
}

char *string;

int encoutlen, decoutlen, enctotallen, dectotallen;

unsigned char *iv[8];
unsigned char  *password[16];
unsigned char enc_outbuf[output_buf_size];
char enc_inbuf[input_buf_size];
unsigned char dec_outbuf[input_buf_size];
char dec_inbuf[output_buf_size];
EVP_CIPHER_CTX ectx;
EVP_CIPHER_CTX dctx;

/*
 * Begin the encode - decode
 *
 * Get our inputs and the random IV
 *
 */

string = argv[1];

RAND_bytes(iv, 8);
RAND_bytes(password, 16);

printf("Entering Encryption Stage:\n\n");
printf("String to encrypt: %s\n\n", string);

EVP_CIPHER_CTX_init(&ectx);


EVP_EncryptInit(&ectx, EVP_bf_cbc(), password, iv);

bzero (&enc_inbuf, input_buf_size);

if(!EVP_EncryptUpdate(&ectx, enc_outbuf, &encoutlen, string, 
strlen(string)))
{
printf("Error whilst EncryptUpdate\n");
return 0;
}

if(!EVP_EncryptFinal(&ectx, enc_outbuf + encoutlen, &enctotallen))
{
printf("Error Whilst EncryptFinal\n");
return 0;
}

encoutlen += enctotallen;

printf("Encryption Successful\n\n");
printf("Entering Decryption Stage\n\n");

EVP_CIPHER_CTX_init(&dctx);
EVP_DecryptInit(&dctx, EVP_bf_cbc(), password, iv);

bzero (&dec_inbuf, output_buf_size);
bzero (&dec_outbuf, input_buf_size);

if (!(EVP_DecryptUpdate(&dctx, dec_outbuf, &decoutlen, enc_outbuf, 
output_buf_size)))
{
printf("Error Whilst DecryptUpdate\n");
return 0;
}

if (!(EVP_DecryptFinal(&dctx, dec_outbuf + decoutlen, &dectotallen)))
{
printf("Error Whilst DecryptFinal\n");
ERR_print_errors_fp(stdout);
return 0;
}

decoutlen += dectotallen;

printf("Decryption Successful\n\n");

printf("Decrypted String is: %s\n", dec_outbuf);

return 0;

}

Re: add extension to an existing (signed) CA certificate

[jehan procaccia]

Peter Sylvester a écrit :

well, if one takes the standard configuration of openssl,
it sets the authoritykey_identifier both the hash and
issuer serial, no exception for the root. comment says
that pkix recommends that.

yes , and the thread you refered me on this list named "Bug in 
"authorityKeyIdentifier" extension ?"
goes in the same direction, altough it is not clear if it concerns THE 
root CA of a hierarchie or sub-CA and final certs ?


on http://marc.info/?l=openssl-dev&m=103640560416217&w=2
I can read
"The keyIdentifier is not used, the only valid content for the 
authorityKeyIdentifier is the issuer's name of the issuer certificate, 
packed with the issuer's certificate serial number."

...
"PKIX recommends the use of the authorityKeyId, and that the French 
Government says you must to have this extension"


Can someone tell me how SSL clients check/verify a 3 level hierarchie ?
is it based on  extension authorityKeyIdentifier ?
At a specific level (1/2/3) it must match keyid ? and /or issuer 
(DirName humane readable ) ? and/or serial of  it's  near (just above) 
parent ?

is this procedure clarified somewhere ?

Now, back to my original problem:
my root CA (http://ca.institut-telecom.fr/pki/IT_MASTER_CA/) doesn't 
contains extension:

X509v3 Basic Constraints: critical
   CA:TRUE
and firefox 3.5 complains aboit it (it is not a CA !)

as long as my sub-ca does contain extension authorityKeyIdentifier with 
keyid/issuer/serial referencing my root CA, I'am stuck with those 
keyid/issuer/serial when I re-sign root-CA ? ( I re-sign it in order to 
add CA:TRUE !)

any other smooth way to change my root-CA without breaking the chain ?

I do not see this recommandation in the rfcs.
at least there is a length paragraph for roots
to have an exception, and nowhere it is said you
must have both link types.

an AKI identifies the KEY, not the certificate btw
I am not sure that the issuer/serial logic is
correctly implementing this in all implementations.
It doesn't mean that the verifying CA certificate
must have this issuer/combination, any other
CA certificate with the same subject DN and same key
is also ok. S

my 2centimes
/P
__
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: pkcs12 with frienlyNames seems to be erroneous

[Willy Weisz]

Using openssl 0.9.8k removes the problems with keytool (I haven't tested
jarsigner, bur the symptoms were the same) and Mozilla (I checked with
Thunderbird and Firefox).

>From the CHANGES file I didn't expect any cure, but I was wrong.

Thanks for the suggestion for a successful solution.

Regards
Willy

Dr. Stephen Henson wrote:
> On Wed, Sep 02, 2009, Willy Weisz wrote:
> 
>> I'm using openssl version 0.9.8h shipped by openSuSE as 0.9.8h-28.10.1
>>
>> The shortest friendlyName I tried to use was 7 letters long - can this
>> be too long?
>>
>> I got the same results when using Java's keytool trying to create a
>> keystore or to add the content of a PKCS#12 file to an existing keystore.
>>
>> Everything works fine when no friendlyName is included in the p12 file.
>>
> 
> I suggest you see if the same problem occurs with OpenSSL 0.9.8k.
> 
> 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
> 


-- 
---
Willy Weisz

European Centre for Parallel Computing at Vienna (VCPC)
  Institute of Scientific Computing
   University of Vienna
 Nordbergstrasse 15/C312
 A-1090 Wien
Tel: (+43 1) 4277 - 39424  Fax: (+43 1) 4277 - 9394
e-mail: we...@vcpc.univie.ac.at
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

OpenSSL.NET version 0.4 released

[Frank Laub]

OpenSSL.NET - Managed wrapper for the OpenSSL toolkit
http://openssl-net.sourceforge.net

I'm pleased to announce the release of version 0.4 of OpenSSL.NET.

Description:
A managed OpenSSL wrapper written in C# for the 2.0 .NET Framework  
that exposes both the Crypto API and the SSL API; based on version  
0.9.8k of libeay32.dll and ssleay32.dll.


You can download a pre-built binary for win32 using the following link:
http://sourceforge.net/projects/openssl-net/files/openssl-net/0.4/openssl.net-0.4-win32.zip/download

In addition, source code is available via git under the New BSD License:
git://openssl-net.git.sourceforge.net/gitroot/openssl-net/openssl-net

Preliminary support for mono has been added and has been tested on  
debian x64 and Mac OS X 10.5.


A big thanks goes out to Ben Henderson for contributing the wrapper  
for the SSL library.


Enjoy,

-Frank

Re: Verify certificate using subordinate ca

[Dr. Stephen Henson]

On Wed, Sep 02, 2009, Yin, Ben 1. (NSN - CN/Cheng Du) wrote:

> OK, regarding the CA deploy, such as, we have a one root ca and 1000 sub ca
> signed by root ca. and each sub ca used as ca by 1000 terminals.so the total
> network size is 1000*1000. All our ca, including root ca and sub ca, was
> stored offline. I need copy sub ca to terminal it was used. So if one of sub
> ca was compromised, what I need to do is sign a new sub ca using root ca and
> copy it to 1000 terminal where sub ca has been compromised. And if root ca
> was compromised, I need to re-deploy CA on 1000*1000 terminal mannuly. That
> is why I want to keep root ca out of the chain.
> 

Including a public key certificate in no way risks the integrity of its
private key as several others have said in this thread.

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: pkcs12 with frienlyNames seems to be erroneous

[Dr. Stephen Henson]

On Wed, Sep 02, 2009, Willy Weisz wrote:

> I'm using openssl version 0.9.8h shipped by openSuSE as 0.9.8h-28.10.1
> 
> The shortest friendlyName I tried to use was 7 letters long - can this
> be too long?
> 
> I got the same results when using Java's keytool trying to create a
> keystore or to add the content of a PKCS#12 file to an existing keystore.
> 
> Everything works fine when no friendlyName is included in the p12 file.
> 

I suggest you see if the same problem occurs with OpenSSL 0.9.8k.

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: pkcs12 with frienlyNames seems to be erroneous

[Willy Weisz]

I'm using openssl version 0.9.8h shipped by openSuSE as 0.9.8h-28.10.1

The shortest friendlyName I tried to use was 7 letters long - can this
be too long?

I got the same results when using Java's keytool trying to create a
keystore or to add the content of a PKCS#12 file to an existing keystore.

Everything works fine when no friendlyName is included in the p12 file.

Regards
Willy


Dr. Stephen Henson schrieb:
> On Tue, Sep 01, 2009, Willy Weisz wrote:
>
>   
>> Being unable to using a PKCS#12 file created by openSSL with 3 different
>> applications - Java jarsigner, Firefox/Thunderbird and KeyStoreBuilder
>> of the package "not-yet-commons-ssl"
>>  - I think that the problem may
>> well be attributed to an error in the PKCS#12 file.
>>
>> All 3 errors are due to the use of the "friendlyName" in the PKCS#12 file.
>> Even so the Mozilla products don't explain why they don't accept the
>> file contents, removing the friendlyName from the the p12 file makes it
>> acceptable.
>> The java utility jarsigner and KeyStorBuilder 0.3.9 issue the error message:
>> "java.io.IOException: Attribute 1.2.840.113549.1.9.20.9.20 should have a
>> value DerInputStream.getLength(): lengthTag=32, too big"
>>
>> OID 1.2.840.113549.1.9.20 represents "PKCS-9 Attribute : friendlyName".
>>
>> KeyStoreBuilder even tracks the error:
>>
>> java.io.IOException: Attribute 1.2.840.113549.1.9.20 should have a value
>> DerInputStream.getLength(): lengthTag=32, too big.
>> at
>> sun.security.pkcs12.PKCS12KeyStore.loadSafeContents(PKCS12KeyStore.java:1426)
>> at
>> sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:1291)
>> at java.security.KeyStore.load(KeyStore.java:1201)
>> at
>> org.apache.commons.ssl.KeyStoreBuilder.tryJKS(KeyStoreBuilder.java:450)
>> at
>> org.apache.commons.ssl.KeyStoreBuilder.parse(KeyStoreBuilder.java:341)
>> at
>> org.apache.commons.ssl.KeyStoreBuilder.build(KeyStoreBuilder.java:98)
>>  at
>> org.apache.commons.ssl.KeyStoreBuilder.main(KeyStoreBuilder.java:540)
>>
>> Even so the problem may be attributed to the applications, I suspect
>> that the fact that it happens with 3 applications rather points to an
>> error in the PKCS#12 file.
>>
>> 
>
> I have not had any issues with friendlyName attributes in PKCS#12 files. What
> version of OpenSSL are you using?
>
> That error suggests the friendlyName might be too long, have you tried a
> smaller one?
>
> 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
>   


-- 
---
Willy Weisz

European Centre for Parallel Computing at Vienna (VCPC)
  Institute of Scientific Computing
   University of Vienna
 Nordbergstrasse 15/C312
 A-1090 Wien
Tel: (+43 1) 4277 - 39424  Fax: (+43 1) 4277 - 9394
e-mail: we...@vcpc.univie.ac.at



smime.p7s
Description: S/MIME Cryptographic Signature

post-connection assertions

[Daniel Mentz]

I'm wondering what's the best way to check the identity of the peer i.e. 
compare the commonName or subjectAltName included in the x509 cert with 
the data I expect.


The book "Network Security with OpenSSL" calls this "Post-connection 
assertions" (page 134).


I already managed to extract all that data from the x509 certificate so 
that's not the issue.


So I call SSL_get_verify_result() and SSL_get_peer_certificate(). My 
question is *when* to call these functions. Some alternatives come into 
my mind. But I do not like any of them:


1. Call those functions when SSL_accept() (or SSL_connect()) returns 
success.
That's not an option for me cos I want to use the implicit connection 
setup provided by SSL_read() and SSL_write()


2. Use SSL_in_init() after every call to SSL_read() or SSL_write() and 
see if the return value changes from true to false.
I don't like that option either because it feels like a hack. Also, I 
guess it only works with SSL_read(). SSL_write() might send data before 
I've got a chance to check if the subjectAltName matches with what I expect.


3. Use SSL_set_verify() and provide a callback function.
This sounds promising but the callback function gets called for every 
certificate in the chain. How can I find out whether the certificate in 
question is the peer's cert and not some intermediate cert?


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

Re: pkcs12 with frienlyNames seems to be erroneous

[Dr. Stephen Henson]

On Tue, Sep 01, 2009, Willy Weisz wrote:

> Being unable to using a PKCS#12 file created by openSSL with 3 different
> applications - Java jarsigner, Firefox/Thunderbird and KeyStoreBuilder
> of the package "not-yet-commons-ssl"
>  - I think that the problem may
> well be attributed to an error in the PKCS#12 file.
> 
> All 3 errors are due to the use of the "friendlyName" in the PKCS#12 file.
> Even so the Mozilla products don't explain why they don't accept the
> file contents, removing the friendlyName from the the p12 file makes it
> acceptable.
> The java utility jarsigner and KeyStorBuilder 0.3.9 issue the error message:
> "java.io.IOException: Attribute 1.2.840.113549.1.9.20.9.20 should have a
> value DerInputStream.getLength(): lengthTag=32, too big"
> 
> OID 1.2.840.113549.1.9.20 represents "PKCS-9 Attribute : friendlyName".
> 
> KeyStoreBuilder even tracks the error:
> 
> java.io.IOException: Attribute 1.2.840.113549.1.9.20 should have a value
> DerInputStream.getLength(): lengthTag=32, too big.
> at
> sun.security.pkcs12.PKCS12KeyStore.loadSafeContents(PKCS12KeyStore.java:1426)
> at
> sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:1291)
> at java.security.KeyStore.load(KeyStore.java:1201)
> at
> org.apache.commons.ssl.KeyStoreBuilder.tryJKS(KeyStoreBuilder.java:450)
> at
> org.apache.commons.ssl.KeyStoreBuilder.parse(KeyStoreBuilder.java:341)
> at
> org.apache.commons.ssl.KeyStoreBuilder.build(KeyStoreBuilder.java:98)
>  at
> org.apache.commons.ssl.KeyStoreBuilder.main(KeyStoreBuilder.java:540)
> 
> Even so the problem may be attributed to the applications, I suspect
> that the fact that it happens with 3 applications rather points to an
> error in the PKCS#12 file.
> 

I have not had any issues with friendlyName attributes in PKCS#12 files. What
version of OpenSSL are you using?

That error suggests the friendlyName might be too long, have you tried a
smaller one?

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 certificate using subordinate ca

[Serge Fonville]

The chain always includes all CAs and certificates. I've done some
googling, and it shows that you can trust 'just' the intermediate CA
without trusting the root CA, altough this kinda obsoletes the purpose
of the root CA. Also, it wholly depends on the applications that use
the certificates for the encrypted connections. For example, IE does
not support trusting just the intermediate CA (in my experience) if
you are developing your own client/server you can trust as you please
on whatever criteria is relevant to you.

Perhaps a good idea to read up on hwo ssl works
http://it.toolbox.com/blogs/securitymonkey/howto-securing-a-website-with-client-ssl-certificates-11500
http://publib.boulder.ibm.com/infocenter/tpfhelp/current/index.jsp?topic=/com.ibm.ztpf-ztpfdf.doc_put.cur/gtps5/s5vctch.html
http://nl.wikipedia.org/wiki/Secure_Sockets_Layer

HTH

Regards,

Serge Fonville

On Wed, Sep 2, 2009 at 12:36 PM, Yin, Ben 1. (NSN - CN/Cheng
Du) wrote:
> I mean does it possible to verify the certificate successfully if chain only 
> including sub ca and certificate singed by sub ca. geiven we trust the sub ca 
> even if it wasn't a self sign root ca.
>
>
> Br
>
> Ben
>
> -Original Message-
> From: owner-openssl-us...@openssl.org 
> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
> Sent: Wednesday, September 02, 2009 1:30 PM
> To: openssl-users@openssl.org
> Subject: Re: Verify certificate using subordinate ca
>
> If you are using client certificates, use a CRL at the server side.
> that way you can assure that only those that you want can connect to
> the server
>
> Regarding the certificates.
> * Distribute the CA certificates (a simple script suffices)
> * Store the certificates and keys on a safe medium you can put in a vault
> * Store only the CA certificates (not the keys) and the server
> certificate and key on your server.
> Obviously all keys are encrypted using a strong password...
>
> Regards,
>
> Serge Fonville
>
>
> To answer your original question, you can not verify a chain without
> all chain members to verify against root --> sub --> client/server
> cert
>
> On Wed, Sep 2, 2009 at 12:02 PM, Yin, Ben 1. (NSN - CN/Cheng
> Du) wrote:
>> Yes. It use openssl lib.
>>
>> My client & server looks like follow to set up sub ca and certificate, the 
>> CERTFILE only include the certificate signed by sub ca. Thanks.
>>
>> ...
>>    if (SSL_CTX_load_verify_locations(ctx, CAFILE, CADIR) != 1)
>>        int_error("Error loading CA file and/or directory");
>>    if (SSL_CTX_set_default_verify_paths(ctx) != 1)
>>        int_error("Error loading default CA file and/or directory");
>>    if (SSL_CTX_use_certificate_chain_file(ctx, CERTFILE) != 1)
>>        int_error("Error loading certificate from file");
>>    if (SSL_CTX_use_PrivateKey_file(ctx, KEYFILE, SSL_FILETYPE_PEM) != 1)
>>        int_error("Error loading private key from file");
>> 
>>
>>
>> Br
>>
>> Ben
>>
>> -Original Message-
>> From: owner-openssl-us...@openssl.org 
>> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
>> Sent: Wednesday, September 02, 2009 12:52 PM
>> To: openssl-users@openssl.org
>> Subject: Re: Verify certificate using subordinate ca
>>
>> Wat exactly are the applications you use, are they compiled against
>> openssl libraries?
>>
>> On Wed, Sep 2, 2009 at 11:49 AM, Yin, Ben 1. (NSN - CN/Cheng
>> Du) wrote:
>>> Yes. When server send certificate signed by sub ca to client. How client 
>>> can verify it only use sub ca. would you please show me the client side 
>>> code? :-)  Thanks.
>>>
>>>
>>> Br
>>>
>>> Ben
>>>
>>> -Original Message-
>>> From: owner-openssl-us...@openssl.org 
>>> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
>>> Sent: Wednesday, September 02, 2009 12:43 PM
>>> To: openssl-users@openssl.org
>>> Subject: Re: Verify certificate using subordinate ca
>>>
>>> Everytime an application connects to an ssl-enabled server the
>>> certificate chain is verified.
>>>
>>> On Wed, Sep 2, 2009 at 11:37 AM, Yin, Ben 1. (NSN - CN/Cheng
>>> Du) wrote:
 Hi,

 What's you mean "If your client application supports that", do you mean I 
 do the verify by client itself, don't use openssl default verify 
 functionality?


 Br

 Ben

 -Original Message-
 From: owner-openssl-us...@openssl.org 
 [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
 Sent: Wednesday, September 02, 2009 11:59 AM
 To: openssl-users@openssl.org
 Subject: Re: Verify certificate using subordinate ca

 If your client application supports that, it could be done. but no
 standard compliant application allows that to my knowledge.

 On Wed, Sep 2, 2009 at 10:35 AM, Yin, Ben 1. (NSN - CN/Cheng
 Du) wrote:
> Hi Serge,
>
> Maybe we can put the root ca into the verification chain if I can prove 
> the verfiy certificate using only sub ca is imposs

RE: Verify certificate using subordinate ca

[Yin, Ben 1. (NSN - CN/Cheng Du)]

I mean does it possible to verify the certificate successfully if chain only 
including sub ca and certificate singed by sub ca. geiven we trust the sub ca 
even if it wasn't a self sign root ca.  


Br

Ben

-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of ext Serge Fonville
Sent: Wednesday, September 02, 2009 1:30 PM
To: openssl-users@openssl.org
Subject: Re: Verify certificate using subordinate ca

If you are using client certificates, use a CRL at the server side.
that way you can assure that only those that you want can connect to
the server

Regarding the certificates.
* Distribute the CA certificates (a simple script suffices)
* Store the certificates and keys on a safe medium you can put in a vault
* Store only the CA certificates (not the keys) and the server
certificate and key on your server.
Obviously all keys are encrypted using a strong password...

Regards,

Serge Fonville


To answer your original question, you can not verify a chain without
all chain members to verify against root --> sub --> client/server
cert

On Wed, Sep 2, 2009 at 12:02 PM, Yin, Ben 1. (NSN - CN/Cheng
Du) wrote:
> Yes. It use openssl lib.
>
> My client & server looks like follow to set up sub ca and certificate, the 
> CERTFILE only include the certificate signed by sub ca. Thanks.
>
> ...
>    if (SSL_CTX_load_verify_locations(ctx, CAFILE, CADIR) != 1)
>        int_error("Error loading CA file and/or directory");
>    if (SSL_CTX_set_default_verify_paths(ctx) != 1)
>        int_error("Error loading default CA file and/or directory");
>    if (SSL_CTX_use_certificate_chain_file(ctx, CERTFILE) != 1)
>        int_error("Error loading certificate from file");
>    if (SSL_CTX_use_PrivateKey_file(ctx, KEYFILE, SSL_FILETYPE_PEM) != 1)
>        int_error("Error loading private key from file");
> 
>
>
> Br
>
> Ben
>
> -Original Message-
> From: owner-openssl-us...@openssl.org 
> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
> Sent: Wednesday, September 02, 2009 12:52 PM
> To: openssl-users@openssl.org
> Subject: Re: Verify certificate using subordinate ca
>
> Wat exactly are the applications you use, are they compiled against
> openssl libraries?
>
> On Wed, Sep 2, 2009 at 11:49 AM, Yin, Ben 1. (NSN - CN/Cheng
> Du) wrote:
>> Yes. When server send certificate signed by sub ca to client. How client can 
>> verify it only use sub ca. would you please show me the client side code? 
>> :-)  Thanks.
>>
>>
>> Br
>>
>> Ben
>>
>> -Original Message-
>> From: owner-openssl-us...@openssl.org 
>> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
>> Sent: Wednesday, September 02, 2009 12:43 PM
>> To: openssl-users@openssl.org
>> Subject: Re: Verify certificate using subordinate ca
>>
>> Everytime an application connects to an ssl-enabled server the
>> certificate chain is verified.
>>
>> On Wed, Sep 2, 2009 at 11:37 AM, Yin, Ben 1. (NSN - CN/Cheng
>> Du) wrote:
>>> Hi,
>>>
>>> What's you mean "If your client application supports that", do you mean I 
>>> do the verify by client itself, don't use openssl default verify 
>>> functionality?
>>>
>>>
>>> Br
>>>
>>> Ben
>>>
>>> -Original Message-
>>> From: owner-openssl-us...@openssl.org 
>>> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
>>> Sent: Wednesday, September 02, 2009 11:59 AM
>>> To: openssl-users@openssl.org
>>> Subject: Re: Verify certificate using subordinate ca
>>>
>>> If your client application supports that, it could be done. but no
>>> standard compliant application allows that to my knowledge.
>>>
>>> On Wed, Sep 2, 2009 at 10:35 AM, Yin, Ben 1. (NSN - CN/Cheng
>>> Du) wrote:
 Hi Serge,

 Maybe we can put the root ca into the verification chain if I can prove 
 the verfiy certificate using only sub ca is impossible. But before that, 
 do you know if it's possible to verfiy certificate without root ca? Thanks.


 Br

 Ben

 -Original Message-
 From: owner-openssl-us...@openssl.org 
 [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
 Sent: Wednesday, September 02, 2009 11:28 AM
 To: openssl-users@openssl.org
 Subject: Re: Verify certificate using subordinate ca

 How do you think compromising a CA would occur, because a CA could
 only becom compromised when someone leaks the key for that specific CA
 And if it happens once, it will likely happen twice. And I hope in
 your best interest, you are not distributing keys to terminals.

 Also, if you need to copy a file to 1000^2 terminals, use a script.
 I assume you have a list of all these terminals (otherwise you have a
 serious problem)

 I assume you are using server certificates and client certificates.
 with these there corresponds a CRL, this crl can be automatically used
 by any clientapplication that us

Re: Verify certificate using subordinate ca

[Serge Fonville]

If you are using client certificates, use a CRL at the server side.
that way you can assure that only those that you want can connect to
the server

Regarding the certificates.
* Distribute the CA certificates (a simple script suffices)
* Store the certificates and keys on a safe medium you can put in a vault
* Store only the CA certificates (not the keys) and the server
certificate and key on your server.
Obviously all keys are encrypted using a strong password...

Regards,

Serge Fonville


To answer your original question, you can not verify a chain without
all chain members to verify against root --> sub --> client/server
cert

On Wed, Sep 2, 2009 at 12:02 PM, Yin, Ben 1. (NSN - CN/Cheng
Du) wrote:
> Yes. It use openssl lib.
>
> My client & server looks like follow to set up sub ca and certificate, the 
> CERTFILE only include the certificate signed by sub ca. Thanks.
>
> ...
>    if (SSL_CTX_load_verify_locations(ctx, CAFILE, CADIR) != 1)
>        int_error("Error loading CA file and/or directory");
>    if (SSL_CTX_set_default_verify_paths(ctx) != 1)
>        int_error("Error loading default CA file and/or directory");
>    if (SSL_CTX_use_certificate_chain_file(ctx, CERTFILE) != 1)
>        int_error("Error loading certificate from file");
>    if (SSL_CTX_use_PrivateKey_file(ctx, KEYFILE, SSL_FILETYPE_PEM) != 1)
>        int_error("Error loading private key from file");
> 
>
>
> Br
>
> Ben
>
> -Original Message-
> From: owner-openssl-us...@openssl.org 
> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
> Sent: Wednesday, September 02, 2009 12:52 PM
> To: openssl-users@openssl.org
> Subject: Re: Verify certificate using subordinate ca
>
> Wat exactly are the applications you use, are they compiled against
> openssl libraries?
>
> On Wed, Sep 2, 2009 at 11:49 AM, Yin, Ben 1. (NSN - CN/Cheng
> Du) wrote:
>> Yes. When server send certificate signed by sub ca to client. How client can 
>> verify it only use sub ca. would you please show me the client side code? 
>> :-)  Thanks.
>>
>>
>> Br
>>
>> Ben
>>
>> -Original Message-
>> From: owner-openssl-us...@openssl.org 
>> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
>> Sent: Wednesday, September 02, 2009 12:43 PM
>> To: openssl-users@openssl.org
>> Subject: Re: Verify certificate using subordinate ca
>>
>> Everytime an application connects to an ssl-enabled server the
>> certificate chain is verified.
>>
>> On Wed, Sep 2, 2009 at 11:37 AM, Yin, Ben 1. (NSN - CN/Cheng
>> Du) wrote:
>>> Hi,
>>>
>>> What's you mean "If your client application supports that", do you mean I 
>>> do the verify by client itself, don't use openssl default verify 
>>> functionality?
>>>
>>>
>>> Br
>>>
>>> Ben
>>>
>>> -Original Message-
>>> From: owner-openssl-us...@openssl.org 
>>> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
>>> Sent: Wednesday, September 02, 2009 11:59 AM
>>> To: openssl-users@openssl.org
>>> Subject: Re: Verify certificate using subordinate ca
>>>
>>> If your client application supports that, it could be done. but no
>>> standard compliant application allows that to my knowledge.
>>>
>>> On Wed, Sep 2, 2009 at 10:35 AM, Yin, Ben 1. (NSN - CN/Cheng
>>> Du) wrote:
 Hi Serge,

 Maybe we can put the root ca into the verification chain if I can prove 
 the verfiy certificate using only sub ca is impossible. But before that, 
 do you know if it's possible to verfiy certificate without root ca? Thanks.


 Br

 Ben

 -Original Message-
 From: owner-openssl-us...@openssl.org 
 [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
 Sent: Wednesday, September 02, 2009 11:28 AM
 To: openssl-users@openssl.org
 Subject: Re: Verify certificate using subordinate ca

 How do you think compromising a CA would occur, because a CA could
 only becom compromised when someone leaks the key for that specific CA
 And if it happens once, it will likely happen twice. And I hope in
 your best interest, you are not distributing keys to terminals.

 Also, if you need to copy a file to 1000^2 terminals, use a script.
 I assume you have a list of all these terminals (otherwise you have a
 serious problem)

 I assume you are using server certificates and client certificates.
 with these there corresponds a CRL, this crl can be automatically used
 by any clientapplication that uses a certificate issued by any CA

 Bacically, are you distributing keys to terminals?

 Regards,

 Serge Fonville

 On Wed, Sep 2, 2009 at 8:21 AM, Yin, Ben 1. (NSN - CN/Cheng
 Du) wrote:
> OK, regarding the CA deploy, such as, we have a one root ca and 1000 sub 
> ca signed by root ca. and each sub ca used as ca by 1000 terminals.so the 
> total network size is 1000*1000. All our ca, including root ca and sub 
> ca, wa

RE: Verify certificate using subordinate ca

[Yin, Ben 1. (NSN - CN/Cheng Du)]

Yes. It use openssl lib.

My client & server looks like follow to set up sub ca and certificate, the 
CERTFILE only include the certificate signed by sub ca. Thanks.

...
if (SSL_CTX_load_verify_locations(ctx, CAFILE, CADIR) != 1)
int_error("Error loading CA file and/or directory");
if (SSL_CTX_set_default_verify_paths(ctx) != 1)
int_error("Error loading default CA file and/or directory");
if (SSL_CTX_use_certificate_chain_file(ctx, CERTFILE) != 1)
int_error("Error loading certificate from file");
if (SSL_CTX_use_PrivateKey_file(ctx, KEYFILE, SSL_FILETYPE_PEM) != 1)
int_error("Error loading private key from file"); 
 


Br

Ben

-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of ext Serge Fonville
Sent: Wednesday, September 02, 2009 12:52 PM
To: openssl-users@openssl.org
Subject: Re: Verify certificate using subordinate ca

Wat exactly are the applications you use, are they compiled against
openssl libraries?

On Wed, Sep 2, 2009 at 11:49 AM, Yin, Ben 1. (NSN - CN/Cheng
Du) wrote:
> Yes. When server send certificate signed by sub ca to client. How client can 
> verify it only use sub ca. would you please show me the client side code? :-) 
>  Thanks.
>
>
> Br
>
> Ben
>
> -Original Message-
> From: owner-openssl-us...@openssl.org 
> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
> Sent: Wednesday, September 02, 2009 12:43 PM
> To: openssl-users@openssl.org
> Subject: Re: Verify certificate using subordinate ca
>
> Everytime an application connects to an ssl-enabled server the
> certificate chain is verified.
>
> On Wed, Sep 2, 2009 at 11:37 AM, Yin, Ben 1. (NSN - CN/Cheng
> Du) wrote:
>> Hi,
>>
>> What's you mean "If your client application supports that", do you mean I do 
>> the verify by client itself, don't use openssl default verify functionality?
>>
>>
>> Br
>>
>> Ben
>>
>> -Original Message-
>> From: owner-openssl-us...@openssl.org 
>> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
>> Sent: Wednesday, September 02, 2009 11:59 AM
>> To: openssl-users@openssl.org
>> Subject: Re: Verify certificate using subordinate ca
>>
>> If your client application supports that, it could be done. but no
>> standard compliant application allows that to my knowledge.
>>
>> On Wed, Sep 2, 2009 at 10:35 AM, Yin, Ben 1. (NSN - CN/Cheng
>> Du) wrote:
>>> Hi Serge,
>>>
>>> Maybe we can put the root ca into the verification chain if I can prove the 
>>> verfiy certificate using only sub ca is impossible. But before that, do you 
>>> know if it's possible to verfiy certificate without root ca? Thanks.
>>>
>>>
>>> Br
>>>
>>> Ben
>>>
>>> -Original Message-
>>> From: owner-openssl-us...@openssl.org 
>>> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
>>> Sent: Wednesday, September 02, 2009 11:28 AM
>>> To: openssl-users@openssl.org
>>> Subject: Re: Verify certificate using subordinate ca
>>>
>>> How do you think compromising a CA would occur, because a CA could
>>> only becom compromised when someone leaks the key for that specific CA
>>> And if it happens once, it will likely happen twice. And I hope in
>>> your best interest, you are not distributing keys to terminals.
>>>
>>> Also, if you need to copy a file to 1000^2 terminals, use a script.
>>> I assume you have a list of all these terminals (otherwise you have a
>>> serious problem)
>>>
>>> I assume you are using server certificates and client certificates.
>>> with these there corresponds a CRL, this crl can be automatically used
>>> by any clientapplication that uses a certificate issued by any CA
>>>
>>> Bacically, are you distributing keys to terminals?
>>>
>>> Regards,
>>>
>>> Serge Fonville
>>>
>>> On Wed, Sep 2, 2009 at 8:21 AM, Yin, Ben 1. (NSN - CN/Cheng
>>> Du) wrote:
 OK, regarding the CA deploy, such as, we have a one root ca and 1000 sub 
 ca signed by root ca. and each sub ca used as ca by 1000 terminals.so the 
 total network size is 1000*1000. All our ca, including root ca and sub ca, 
 was stored offline. I need copy sub ca to terminal it was used. So if one 
 of sub ca was compromised, what I need to do is sign a new sub ca using 
 root ca and copy it to 1000 terminal where sub ca has been compromised. 
 And if root ca was compromised, I need to re-deploy CA on 1000*1000 
 terminal mannuly. That is why I want to keep root ca out of the chain. And 
 only using sub ca and certificate to do the verification.  Dose it 
 possible? It seems that openssl always try to find the issuer of sub ca 
 during tht chain verification because it wasn't self signed root ca.


 Br

 Ben

 -Original Message-
 From: owner-openssl-us...@openssl.org 
 [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
 Sent: Tuesday, September 01, 2009 5:14 PM

Re: Verify certificate using subordinate ca

[Serge Fonville]

Wat exactly are the applications you use, are they compiled against
openssl libraries?

On Wed, Sep 2, 2009 at 11:49 AM, Yin, Ben 1. (NSN - CN/Cheng
Du) wrote:
> Yes. When server send certificate signed by sub ca to client. How client can 
> verify it only use sub ca. would you please show me the client side code? :-) 
>  Thanks.
>
>
> Br
>
> Ben
>
> -Original Message-
> From: owner-openssl-us...@openssl.org 
> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
> Sent: Wednesday, September 02, 2009 12:43 PM
> To: openssl-users@openssl.org
> Subject: Re: Verify certificate using subordinate ca
>
> Everytime an application connects to an ssl-enabled server the
> certificate chain is verified.
>
> On Wed, Sep 2, 2009 at 11:37 AM, Yin, Ben 1. (NSN - CN/Cheng
> Du) wrote:
>> Hi,
>>
>> What's you mean "If your client application supports that", do you mean I do 
>> the verify by client itself, don't use openssl default verify functionality?
>>
>>
>> Br
>>
>> Ben
>>
>> -Original Message-
>> From: owner-openssl-us...@openssl.org 
>> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
>> Sent: Wednesday, September 02, 2009 11:59 AM
>> To: openssl-users@openssl.org
>> Subject: Re: Verify certificate using subordinate ca
>>
>> If your client application supports that, it could be done. but no
>> standard compliant application allows that to my knowledge.
>>
>> On Wed, Sep 2, 2009 at 10:35 AM, Yin, Ben 1. (NSN - CN/Cheng
>> Du) wrote:
>>> Hi Serge,
>>>
>>> Maybe we can put the root ca into the verification chain if I can prove the 
>>> verfiy certificate using only sub ca is impossible. But before that, do you 
>>> know if it's possible to verfiy certificate without root ca? Thanks.
>>>
>>>
>>> Br
>>>
>>> Ben
>>>
>>> -Original Message-
>>> From: owner-openssl-us...@openssl.org 
>>> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
>>> Sent: Wednesday, September 02, 2009 11:28 AM
>>> To: openssl-users@openssl.org
>>> Subject: Re: Verify certificate using subordinate ca
>>>
>>> How do you think compromising a CA would occur, because a CA could
>>> only becom compromised when someone leaks the key for that specific CA
>>> And if it happens once, it will likely happen twice. And I hope in
>>> your best interest, you are not distributing keys to terminals.
>>>
>>> Also, if you need to copy a file to 1000^2 terminals, use a script.
>>> I assume you have a list of all these terminals (otherwise you have a
>>> serious problem)
>>>
>>> I assume you are using server certificates and client certificates.
>>> with these there corresponds a CRL, this crl can be automatically used
>>> by any clientapplication that uses a certificate issued by any CA
>>>
>>> Bacically, are you distributing keys to terminals?
>>>
>>> Regards,
>>>
>>> Serge Fonville
>>>
>>> On Wed, Sep 2, 2009 at 8:21 AM, Yin, Ben 1. (NSN - CN/Cheng
>>> Du) wrote:
 OK, regarding the CA deploy, such as, we have a one root ca and 1000 sub 
 ca signed by root ca. and each sub ca used as ca by 1000 terminals.so the 
 total network size is 1000*1000. All our ca, including root ca and sub ca, 
 was stored offline. I need copy sub ca to terminal it was used. So if one 
 of sub ca was compromised, what I need to do is sign a new sub ca using 
 root ca and copy it to 1000 terminal where sub ca has been compromised. 
 And if root ca was compromised, I need to re-deploy CA on 1000*1000 
 terminal mannuly. That is why I want to keep root ca out of the chain. And 
 only using sub ca and certificate to do the verification.  Dose it 
 possible? It seems that openssl always try to find the issuer of sub ca 
 during tht chain verification because it wasn't self signed root ca.


 Br

 Ben

 -Original Message-
 From: owner-openssl-us...@openssl.org 
 [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
 Sent: Tuesday, September 01, 2009 5:14 PM
 To: openssl-users@openssl.org
 Subject: Re: Verify certificate using subordinate ca

 I don't see your problem honestly. Figuring out a private key is close
 to impossible.
 And stealing it, well, that is more related to security itself than to
 the actual key being secure or not.

 >From what I understand, a chain works somewhat like this

 you
 --peter
 john
 --carl

 You talk to peter, peter is trusted by john, john is trusted by carl,
 you trust carl
 Say if you were to obsolete carl in this chain (by trusting john) john
 would then become the root
 If this is the case, why would you want to have carl at all?

 Thawte, verisign etc work the same way

 Also, why is distributing a CA cert so difficult?
 What is your environment?
 What applications are using the certs?
 And how do they verify the chain?

 Again, without the

RE: Verify certificate using subordinate ca

[Yin, Ben 1. (NSN - CN/Cheng Du)]

Yes. When server send certificate signed by sub ca to client. How client can 
verify it only use sub ca. would you please show me the client side code? :-)  
Thanks.


Br

Ben

-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of ext Serge Fonville
Sent: Wednesday, September 02, 2009 12:43 PM
To: openssl-users@openssl.org
Subject: Re: Verify certificate using subordinate ca

Everytime an application connects to an ssl-enabled server the
certificate chain is verified.

On Wed, Sep 2, 2009 at 11:37 AM, Yin, Ben 1. (NSN - CN/Cheng
Du) wrote:
> Hi,
>
> What's you mean "If your client application supports that", do you mean I do 
> the verify by client itself, don't use openssl default verify functionality?
>
>
> Br
>
> Ben
>
> -Original Message-
> From: owner-openssl-us...@openssl.org 
> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
> Sent: Wednesday, September 02, 2009 11:59 AM
> To: openssl-users@openssl.org
> Subject: Re: Verify certificate using subordinate ca
>
> If your client application supports that, it could be done. but no
> standard compliant application allows that to my knowledge.
>
> On Wed, Sep 2, 2009 at 10:35 AM, Yin, Ben 1. (NSN - CN/Cheng
> Du) wrote:
>> Hi Serge,
>>
>> Maybe we can put the root ca into the verification chain if I can prove the 
>> verfiy certificate using only sub ca is impossible. But before that, do you 
>> know if it's possible to verfiy certificate without root ca? Thanks.
>>
>>
>> Br
>>
>> Ben
>>
>> -Original Message-
>> From: owner-openssl-us...@openssl.org 
>> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
>> Sent: Wednesday, September 02, 2009 11:28 AM
>> To: openssl-users@openssl.org
>> Subject: Re: Verify certificate using subordinate ca
>>
>> How do you think compromising a CA would occur, because a CA could
>> only becom compromised when someone leaks the key for that specific CA
>> And if it happens once, it will likely happen twice. And I hope in
>> your best interest, you are not distributing keys to terminals.
>>
>> Also, if you need to copy a file to 1000^2 terminals, use a script.
>> I assume you have a list of all these terminals (otherwise you have a
>> serious problem)
>>
>> I assume you are using server certificates and client certificates.
>> with these there corresponds a CRL, this crl can be automatically used
>> by any clientapplication that uses a certificate issued by any CA
>>
>> Bacically, are you distributing keys to terminals?
>>
>> Regards,
>>
>> Serge Fonville
>>
>> On Wed, Sep 2, 2009 at 8:21 AM, Yin, Ben 1. (NSN - CN/Cheng
>> Du) wrote:
>>> OK, regarding the CA deploy, such as, we have a one root ca and 1000 sub ca 
>>> signed by root ca. and each sub ca used as ca by 1000 terminals.so the 
>>> total network size is 1000*1000. All our ca, including root ca and sub ca, 
>>> was stored offline. I need copy sub ca to terminal it was used. So if one 
>>> of sub ca was compromised, what I need to do is sign a new sub ca using 
>>> root ca and copy it to 1000 terminal where sub ca has been compromised. And 
>>> if root ca was compromised, I need to re-deploy CA on 1000*1000 terminal 
>>> mannuly. That is why I want to keep root ca out of the chain. And only 
>>> using sub ca and certificate to do the verification.  Dose it possible? It 
>>> seems that openssl always try to find the issuer of sub ca during tht chain 
>>> verification because it wasn't self signed root ca.
>>>
>>>
>>> Br
>>>
>>> Ben
>>>
>>> -Original Message-
>>> From: owner-openssl-us...@openssl.org 
>>> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
>>> Sent: Tuesday, September 01, 2009 5:14 PM
>>> To: openssl-users@openssl.org
>>> Subject: Re: Verify certificate using subordinate ca
>>>
>>> I don't see your problem honestly. Figuring out a private key is close
>>> to impossible.
>>> And stealing it, well, that is more related to security itself than to
>>> the actual key being secure or not.
>>>
>>> >From what I understand, a chain works somewhat like this
>>>
>>> you
>>> --peter
>>> john
>>> --carl
>>>
>>> You talk to peter, peter is trusted by john, john is trusted by carl,
>>> you trust carl
>>> Say if you were to obsolete carl in this chain (by trusting john) john
>>> would then become the root
>>> If this is the case, why would you want to have carl at all?
>>>
>>> Thawte, verisign etc work the same way
>>>
>>> Also, why is distributing a CA cert so difficult?
>>> What is your environment?
>>> What applications are using the certs?
>>> And how do they verify the chain?
>>>
>>> Again, without the key for each CA it can't be compromised
>>> Has this actually happened or is this someone eing paranoid?
>>>
>>> Who has created the chain?
>>>
>>> I'm still not clear of the purpose of the root ca if it should not
>>> need to be trusted
>>>
>>> Regards,
>>>
>>> Serge Fonville
>>>
>>> On Tue, Sep 1, 2009 

Re: Verify certificate using subordinate ca

[Serge Fonville]

Everytime an application connects to an ssl-enabled server the
certificate chain is verified.

On Wed, Sep 2, 2009 at 11:37 AM, Yin, Ben 1. (NSN - CN/Cheng
Du) wrote:
> Hi,
>
> What's you mean "If your client application supports that", do you mean I do 
> the verify by client itself, don't use openssl default verify functionality?
>
>
> Br
>
> Ben
>
> -Original Message-
> From: owner-openssl-us...@openssl.org 
> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
> Sent: Wednesday, September 02, 2009 11:59 AM
> To: openssl-users@openssl.org
> Subject: Re: Verify certificate using subordinate ca
>
> If your client application supports that, it could be done. but no
> standard compliant application allows that to my knowledge.
>
> On Wed, Sep 2, 2009 at 10:35 AM, Yin, Ben 1. (NSN - CN/Cheng
> Du) wrote:
>> Hi Serge,
>>
>> Maybe we can put the root ca into the verification chain if I can prove the 
>> verfiy certificate using only sub ca is impossible. But before that, do you 
>> know if it's possible to verfiy certificate without root ca? Thanks.
>>
>>
>> Br
>>
>> Ben
>>
>> -Original Message-
>> From: owner-openssl-us...@openssl.org 
>> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
>> Sent: Wednesday, September 02, 2009 11:28 AM
>> To: openssl-users@openssl.org
>> Subject: Re: Verify certificate using subordinate ca
>>
>> How do you think compromising a CA would occur, because a CA could
>> only becom compromised when someone leaks the key for that specific CA
>> And if it happens once, it will likely happen twice. And I hope in
>> your best interest, you are not distributing keys to terminals.
>>
>> Also, if you need to copy a file to 1000^2 terminals, use a script.
>> I assume you have a list of all these terminals (otherwise you have a
>> serious problem)
>>
>> I assume you are using server certificates and client certificates.
>> with these there corresponds a CRL, this crl can be automatically used
>> by any clientapplication that uses a certificate issued by any CA
>>
>> Bacically, are you distributing keys to terminals?
>>
>> Regards,
>>
>> Serge Fonville
>>
>> On Wed, Sep 2, 2009 at 8:21 AM, Yin, Ben 1. (NSN - CN/Cheng
>> Du) wrote:
>>> OK, regarding the CA deploy, such as, we have a one root ca and 1000 sub ca 
>>> signed by root ca. and each sub ca used as ca by 1000 terminals.so the 
>>> total network size is 1000*1000. All our ca, including root ca and sub ca, 
>>> was stored offline. I need copy sub ca to terminal it was used. So if one 
>>> of sub ca was compromised, what I need to do is sign a new sub ca using 
>>> root ca and copy it to 1000 terminal where sub ca has been compromised. And 
>>> if root ca was compromised, I need to re-deploy CA on 1000*1000 terminal 
>>> mannuly. That is why I want to keep root ca out of the chain. And only 
>>> using sub ca and certificate to do the verification.  Dose it possible? It 
>>> seems that openssl always try to find the issuer of sub ca during tht chain 
>>> verification because it wasn't self signed root ca.
>>>
>>>
>>> Br
>>>
>>> Ben
>>>
>>> -Original Message-
>>> From: owner-openssl-us...@openssl.org 
>>> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
>>> Sent: Tuesday, September 01, 2009 5:14 PM
>>> To: openssl-users@openssl.org
>>> Subject: Re: Verify certificate using subordinate ca
>>>
>>> I don't see your problem honestly. Figuring out a private key is close
>>> to impossible.
>>> And stealing it, well, that is more related to security itself than to
>>> the actual key being secure or not.
>>>
>>> >From what I understand, a chain works somewhat like this
>>>
>>> you
>>> --peter
>>> john
>>> --carl
>>>
>>> You talk to peter, peter is trusted by john, john is trusted by carl,
>>> you trust carl
>>> Say if you were to obsolete carl in this chain (by trusting john) john
>>> would then become the root
>>> If this is the case, why would you want to have carl at all?
>>>
>>> Thawte, verisign etc work the same way
>>>
>>> Also, why is distributing a CA cert so difficult?
>>> What is your environment?
>>> What applications are using the certs?
>>> And how do they verify the chain?
>>>
>>> Again, without the key for each CA it can't be compromised
>>> Has this actually happened or is this someone eing paranoid?
>>>
>>> Who has created the chain?
>>>
>>> I'm still not clear of the purpose of the root ca if it should not
>>> need to be trusted
>>>
>>> Regards,
>>>
>>> Serge Fonville
>>>
>>> On Tue, Sep 1, 2009 at 3:52 PM, Yin, Ben 1. (NSN - CN/Cheng
>>> Du) wrote:
 No. In our enviroment. The root CA private key is isolated and absolutly 
 safe. Regarding the compromised, I means CA can't be trusted any more, 
 Such as the private key was stolen some how or someone find a way to 
 figure out private key for one CA. it easy to set up new sub ca in one 
 domain if those compromise happened on sub ca. but if it happened on root 
>>

RE: Verify certificate using subordinate ca

[Yin, Ben 1. (NSN - CN/Cheng Du)]

Hi,

What's you mean "If your client application supports that", do you mean I do 
the verify by client itself, don't use openssl default verify functionality? 


Br

Ben

-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of ext Serge Fonville
Sent: Wednesday, September 02, 2009 11:59 AM
To: openssl-users@openssl.org
Subject: Re: Verify certificate using subordinate ca

If your client application supports that, it could be done. but no
standard compliant application allows that to my knowledge.

On Wed, Sep 2, 2009 at 10:35 AM, Yin, Ben 1. (NSN - CN/Cheng
Du) wrote:
> Hi Serge,
>
> Maybe we can put the root ca into the verification chain if I can prove the 
> verfiy certificate using only sub ca is impossible. But before that, do you 
> know if it's possible to verfiy certificate without root ca? Thanks.
>
>
> Br
>
> Ben
>
> -Original Message-
> From: owner-openssl-us...@openssl.org 
> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
> Sent: Wednesday, September 02, 2009 11:28 AM
> To: openssl-users@openssl.org
> Subject: Re: Verify certificate using subordinate ca
>
> How do you think compromising a CA would occur, because a CA could
> only becom compromised when someone leaks the key for that specific CA
> And if it happens once, it will likely happen twice. And I hope in
> your best interest, you are not distributing keys to terminals.
>
> Also, if you need to copy a file to 1000^2 terminals, use a script.
> I assume you have a list of all these terminals (otherwise you have a
> serious problem)
>
> I assume you are using server certificates and client certificates.
> with these there corresponds a CRL, this crl can be automatically used
> by any clientapplication that uses a certificate issued by any CA
>
> Bacically, are you distributing keys to terminals?
>
> Regards,
>
> Serge Fonville
>
> On Wed, Sep 2, 2009 at 8:21 AM, Yin, Ben 1. (NSN - CN/Cheng
> Du) wrote:
>> OK, regarding the CA deploy, such as, we have a one root ca and 1000 sub ca 
>> signed by root ca. and each sub ca used as ca by 1000 terminals.so the total 
>> network size is 1000*1000. All our ca, including root ca and sub ca, was 
>> stored offline. I need copy sub ca to terminal it was used. So if one of sub 
>> ca was compromised, what I need to do is sign a new sub ca using root ca and 
>> copy it to 1000 terminal where sub ca has been compromised. And if root ca 
>> was compromised, I need to re-deploy CA on 1000*1000 terminal mannuly. That 
>> is why I want to keep root ca out of the chain. And only using sub ca and 
>> certificate to do the verification.  Dose it possible? It seems that openssl 
>> always try to find the issuer of sub ca during tht chain verification 
>> because it wasn't self signed root ca.
>>
>>
>> Br
>>
>> Ben
>>
>> -Original Message-
>> From: owner-openssl-us...@openssl.org 
>> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
>> Sent: Tuesday, September 01, 2009 5:14 PM
>> To: openssl-users@openssl.org
>> Subject: Re: Verify certificate using subordinate ca
>>
>> I don't see your problem honestly. Figuring out a private key is close
>> to impossible.
>> And stealing it, well, that is more related to security itself than to
>> the actual key being secure or not.
>>
>> >From what I understand, a chain works somewhat like this
>>
>> you
>> --peter
>> john
>> --carl
>>
>> You talk to peter, peter is trusted by john, john is trusted by carl,
>> you trust carl
>> Say if you were to obsolete carl in this chain (by trusting john) john
>> would then become the root
>> If this is the case, why would you want to have carl at all?
>>
>> Thawte, verisign etc work the same way
>>
>> Also, why is distributing a CA cert so difficult?
>> What is your environment?
>> What applications are using the certs?
>> And how do they verify the chain?
>>
>> Again, without the key for each CA it can't be compromised
>> Has this actually happened or is this someone eing paranoid?
>>
>> Who has created the chain?
>>
>> I'm still not clear of the purpose of the root ca if it should not
>> need to be trusted
>>
>> Regards,
>>
>> Serge Fonville
>>
>> On Tue, Sep 1, 2009 at 3:52 PM, Yin, Ben 1. (NSN - CN/Cheng
>> Du) wrote:
>>> No. In our enviroment. The root CA private key is isolated and absolutly 
>>> safe. Regarding the compromised, I means CA can't be trusted any more, Such 
>>> as the private key was stolen some how or someone find a way to figure out 
>>> private key for one CA. it easy to set up new sub ca in one domain if those 
>>> compromise happened on sub ca. but if it happened on root ca, it's quite 
>>> hard to fix the our whole network. Thanks.
>>>
>>>
>>> Br
>>>
>>> Ben
>>>
>>> -Original Message-
>>> From: owner-openssl-us...@openssl.org 
>>> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
>>> Sent: Tuesday, September 01, 2009 4:31 PM
>>> To: openssl-users@

Re: Verify certificate using subordinate ca

[Serge Fonville]

If your client application supports that, it could be done. but no
standard compliant application allows that to my knowledge.

On Wed, Sep 2, 2009 at 10:35 AM, Yin, Ben 1. (NSN - CN/Cheng
Du) wrote:
> Hi Serge,
>
> Maybe we can put the root ca into the verification chain if I can prove the 
> verfiy certificate using only sub ca is impossible. But before that, do you 
> know if it's possible to verfiy certificate without root ca? Thanks.
>
>
> Br
>
> Ben
>
> -Original Message-
> From: owner-openssl-us...@openssl.org 
> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
> Sent: Wednesday, September 02, 2009 11:28 AM
> To: openssl-users@openssl.org
> Subject: Re: Verify certificate using subordinate ca
>
> How do you think compromising a CA would occur, because a CA could
> only becom compromised when someone leaks the key for that specific CA
> And if it happens once, it will likely happen twice. And I hope in
> your best interest, you are not distributing keys to terminals.
>
> Also, if you need to copy a file to 1000^2 terminals, use a script.
> I assume you have a list of all these terminals (otherwise you have a
> serious problem)
>
> I assume you are using server certificates and client certificates.
> with these there corresponds a CRL, this crl can be automatically used
> by any clientapplication that uses a certificate issued by any CA
>
> Bacically, are you distributing keys to terminals?
>
> Regards,
>
> Serge Fonville
>
> On Wed, Sep 2, 2009 at 8:21 AM, Yin, Ben 1. (NSN - CN/Cheng
> Du) wrote:
>> OK, regarding the CA deploy, such as, we have a one root ca and 1000 sub ca 
>> signed by root ca. and each sub ca used as ca by 1000 terminals.so the total 
>> network size is 1000*1000. All our ca, including root ca and sub ca, was 
>> stored offline. I need copy sub ca to terminal it was used. So if one of sub 
>> ca was compromised, what I need to do is sign a new sub ca using root ca and 
>> copy it to 1000 terminal where sub ca has been compromised. And if root ca 
>> was compromised, I need to re-deploy CA on 1000*1000 terminal mannuly. That 
>> is why I want to keep root ca out of the chain. And only using sub ca and 
>> certificate to do the verification.  Dose it possible? It seems that openssl 
>> always try to find the issuer of sub ca during tht chain verification 
>> because it wasn't self signed root ca.
>>
>>
>> Br
>>
>> Ben
>>
>> -Original Message-
>> From: owner-openssl-us...@openssl.org 
>> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
>> Sent: Tuesday, September 01, 2009 5:14 PM
>> To: openssl-users@openssl.org
>> Subject: Re: Verify certificate using subordinate ca
>>
>> I don't see your problem honestly. Figuring out a private key is close
>> to impossible.
>> And stealing it, well, that is more related to security itself than to
>> the actual key being secure or not.
>>
>> >From what I understand, a chain works somewhat like this
>>
>> you
>> --peter
>> john
>> --carl
>>
>> You talk to peter, peter is trusted by john, john is trusted by carl,
>> you trust carl
>> Say if you were to obsolete carl in this chain (by trusting john) john
>> would then become the root
>> If this is the case, why would you want to have carl at all?
>>
>> Thawte, verisign etc work the same way
>>
>> Also, why is distributing a CA cert so difficult?
>> What is your environment?
>> What applications are using the certs?
>> And how do they verify the chain?
>>
>> Again, without the key for each CA it can't be compromised
>> Has this actually happened or is this someone eing paranoid?
>>
>> Who has created the chain?
>>
>> I'm still not clear of the purpose of the root ca if it should not
>> need to be trusted
>>
>> Regards,
>>
>> Serge Fonville
>>
>> On Tue, Sep 1, 2009 at 3:52 PM, Yin, Ben 1. (NSN - CN/Cheng
>> Du) wrote:
>>> No. In our enviroment. The root CA private key is isolated and absolutly 
>>> safe. Regarding the compromised, I means CA can't be trusted any more, Such 
>>> as the private key was stolen some how or someone find a way to figure out 
>>> private key for one CA. it easy to set up new sub ca in one domain if those 
>>> compromise happened on sub ca. but if it happened on root ca, it's quite 
>>> hard to fix the our whole network. Thanks.
>>>
>>>
>>> Br
>>>
>>> Ben
>>>
>>> -Original Message-
>>> From: owner-openssl-us...@openssl.org 
>>> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
>>> Sent: Tuesday, September 01, 2009 4:31 PM
>>> To: openssl-users@openssl.org
>>> Subject: Re: Verify certificate using subordinate ca
>>>
>>> Based on what you state.
>>> There is no purpose for the root CA.
>>>
>>> What do you mean by compromised.
>>> If you publish a CA certificate to clients, it does not include the
>>> key. (normally)
>>> So the only thing a client can do is use it in the session at best.
>>> There is NO way a client can use a CA certificate to sign anything
>>> without the corre

Memory leak in threaded server

[Robin Seggelmann]

Hi all,
I have written an DTLS echo server and client for testing purposes. In  
this case I want to test my new DTLSv1_listen() function, which waits  
for new connections with responding to ClientHellos with  
HelloVerifyRequest messages until a ClientHello with a valid cookie  
arrives. The SSL object can then be used for that connection and  
DTLSv1_listen() is called with a new SSL object again. Unfortunately  
the server has a memory leak which I was unable to find yet. According  
to my debug tools the problem seems to be that some certificates  
aren't freed. However, there are no leaks in terms of memory that is  
not accessible anymore. Here is the scheme of my server:


void start_server(int port, in_addr_t* local_address) {

... (variables) ...

THREAD_setup();
OpenSSL_add_ssl_algorithms();
SSL_load_error_strings();
ctx = SSL_CTX_new(DTLSv1_server_method());
SSL_CTX_set_cipher_list(ctx, "ALL:NULL:eNULL:aNULL");
pid = getpid();
if( !SSL_CTX_set_session_id_context(ctx, (void*)&pid, sizeof pid) )
perror("SSL_CTX_set_session_id_context");

	if (!SSL_CTX_use_certificate_file(ctx, "certs/server-cert.pem",  
SSL_FILETYPE_PEM))

printf("\nERROR: no certificate found!");

	if (!SSL_CTX_use_PrivateKey_file(ctx, "certs/server-key.pem",  
SSL_FILETYPE_PEM))

printf("\nERROR: no private key found!");

if (!SSL_CTX_check_private_key (ctx))
printf("\nERROR: invalid private key!");

/* Client has to authenticate */
	SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | SSL_VERIFY_CLIENT_ONCE,  
dtls_verify_callback);


SSL_CTX_set_read_ahead(ctx, 1);
SSL_CTX_set_cookie_generate_cb(ctx, generate_cookie);
SSL_CTX_set_cookie_verify_cb(ctx, verify_cookie);

... (create listening socket) ...

while (1) {
memset(&client_addr, 0, sizeof(struct sockaddr));

/* Create BIO */
bio = BIO_new_dgram(fd, BIO_NOCLOSE);

/* Set and activate timeouts */
timeout.tv_sec = 5;
timeout.tv_usec = 0;
BIO_ctrl(bio, BIO_CTRL_DGRAM_SET_RECV_TIMEOUT, 0, &timeout);

ssl = SSL_new(ctx);

SSL_set_bio(ssl, bio, bio);
SSL_set_options(ssl, SSL_OP_COOKIE_EXCHANGE);

while (!DTLSv1_listen(ssl, &client_addr));

info = (struct pass_info*) malloc (sizeof(struct pass_info));
memcpy(&info->server_addr, &server_addr, sizeof(struct 
sockaddr));
memcpy(&info->client_addr, &client_addr, sizeof(struct 
sockaddr));
info->ssl = ssl;

if (pthread_create( &tid, NULL, connection_handle, info) != 0) {
perror("pthread_create");
exit(1);
}
ERR_remove_state(0);
}

THREAD_cleanup();
}


The function connection_handle is called when DTLSv1_listen() returned  
and therefore a new connection is about to be established. The SSL  
object is passed and the handshake finished before data transmission  
begins.


void* connection_handle(void *info) {

... (variables) ...

pthread_detach(pthread_self());

... (created connected socket) ...

/* Set new fd and set BIO to connected */
BIO_set_fd(SSL_get_rbio(ssl), fd, BIO_NOCLOSE);
	BIO_ctrl(SSL_get_rbio(ssl), BIO_CTRL_DGRAM_SET_CONNECTED, 0,  
client_addr);


/* Finish handshake */
if(SSL_accept(ssl) <= 0) {
perror("SSL_accept");
goto cleanup;
}

... (read and write until client disconnects) ...

SSL_shutdown(ssl);

cleanup:
close(fd);
free(info);
SSL_free(ssl);
ERR_remove_state(0);
pthread_exit( (void *) NULL );
}

Any suggestions where I forgot any free or threading function? I also  
read about a built-in memory leak detection in OpenSSL but didn't find  
anything in the documentation. Since it might help, how do I use that?  
When I use a shell script which continously starts a client which  
connects, sends some messages and disconnects, the server is working  
fine but constantly allocats memory which is never freed. Since the  
client initiates the shutdown, there is no problem with an unfinished  
shutdown process. The server's SSL_shutdown() always returns 1.


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

RE: Verify certificate using subordinate ca

[Yin, Ben 1. (NSN - CN/Cheng Du)]

Hi Serge,

Maybe we can put the root ca into the verification chain if I can prove the 
verfiy certificate using only sub ca is impossible. But before that, do you 
know if it's possible to verfiy certificate without root ca? Thanks.


Br

Ben

-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of ext Serge Fonville
Sent: Wednesday, September 02, 2009 11:28 AM
To: openssl-users@openssl.org
Subject: Re: Verify certificate using subordinate ca

How do you think compromising a CA would occur, because a CA could
only becom compromised when someone leaks the key for that specific CA
And if it happens once, it will likely happen twice. And I hope in
your best interest, you are not distributing keys to terminals.

Also, if you need to copy a file to 1000^2 terminals, use a script.
I assume you have a list of all these terminals (otherwise you have a
serious problem)

I assume you are using server certificates and client certificates.
with these there corresponds a CRL, this crl can be automatically used
by any clientapplication that uses a certificate issued by any CA

Bacically, are you distributing keys to terminals?

Regards,

Serge Fonville

On Wed, Sep 2, 2009 at 8:21 AM, Yin, Ben 1. (NSN - CN/Cheng
Du) wrote:
> OK, regarding the CA deploy, such as, we have a one root ca and 1000 sub ca 
> signed by root ca. and each sub ca used as ca by 1000 terminals.so the total 
> network size is 1000*1000. All our ca, including root ca and sub ca, was 
> stored offline. I need copy sub ca to terminal it was used. So if one of sub 
> ca was compromised, what I need to do is sign a new sub ca using root ca and 
> copy it to 1000 terminal where sub ca has been compromised. And if root ca 
> was compromised, I need to re-deploy CA on 1000*1000 terminal mannuly. That 
> is why I want to keep root ca out of the chain. And only using sub ca and 
> certificate to do the verification.  Dose it possible? It seems that openssl 
> always try to find the issuer of sub ca during tht chain verification because 
> it wasn't self signed root ca.
>
>
> Br
>
> Ben
>
> -Original Message-
> From: owner-openssl-us...@openssl.org 
> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
> Sent: Tuesday, September 01, 2009 5:14 PM
> To: openssl-users@openssl.org
> Subject: Re: Verify certificate using subordinate ca
>
> I don't see your problem honestly. Figuring out a private key is close
> to impossible.
> And stealing it, well, that is more related to security itself than to
> the actual key being secure or not.
>
> >From what I understand, a chain works somewhat like this
>
> you
> --peter
> john
> --carl
>
> You talk to peter, peter is trusted by john, john is trusted by carl,
> you trust carl
> Say if you were to obsolete carl in this chain (by trusting john) john
> would then become the root
> If this is the case, why would you want to have carl at all?
>
> Thawte, verisign etc work the same way
>
> Also, why is distributing a CA cert so difficult?
> What is your environment?
> What applications are using the certs?
> And how do they verify the chain?
>
> Again, without the key for each CA it can't be compromised
> Has this actually happened or is this someone eing paranoid?
>
> Who has created the chain?
>
> I'm still not clear of the purpose of the root ca if it should not
> need to be trusted
>
> Regards,
>
> Serge Fonville
>
> On Tue, Sep 1, 2009 at 3:52 PM, Yin, Ben 1. (NSN - CN/Cheng
> Du) wrote:
>> No. In our enviroment. The root CA private key is isolated and absolutly 
>> safe. Regarding the compromised, I means CA can't be trusted any more, Such 
>> as the private key was stolen some how or someone find a way to figure out 
>> private key for one CA. it easy to set up new sub ca in one domain if those 
>> compromise happened on sub ca. but if it happened on root ca, it's quite 
>> hard to fix the our whole network. Thanks.
>>
>>
>> Br
>>
>> Ben
>>
>> -Original Message-
>> From: owner-openssl-us...@openssl.org 
>> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
>> Sent: Tuesday, September 01, 2009 4:31 PM
>> To: openssl-users@openssl.org
>> Subject: Re: Verify certificate using subordinate ca
>>
>> Based on what you state.
>> There is no purpose for the root CA.
>>
>> What do you mean by compromised.
>> If you publish a CA certificate to clients, it does not include the
>> key. (normally)
>> So the only thing a client can do is use it in the session at best.
>> There is NO way a client can use a CA certificate to sign anything
>> without the corresponding key.
>>
>> I have a chain on my website, and noone (except me, because I can
>> access the server) is able to sign anything. Since the CAs are only
>> used for signing and verifying and not for encrypting, if the CA keys
>> are stored safely, there is no 'compromise'
>>
>> Are you distributing the keys as well?
>>
>> HTH
>>
>> Regards,
>>
>> Serg

Issue with SSL sockets & pthreads

[Laura Arhire]

I'm having a bit of an issue with something I encountered while unit 
testing my socket classes - each test basically creates a thread on 
which a server socket listens. From the main thread I connect a client 
to the server socket. I've found that after about 10-15 such tests I 
cannot create new threads - so I was wondering if I might have missed 
something clearing up resources (the pthread_create method returns with 
EAGAIN, which means insufficient resources). This only happens with ssl 
sockets when I connect a client, if I use normal sockets everything 
works well.


I have the following code, stripped of error handling for clarity (I've 
marked with * lines which are missing/different in the normal socket 
implementation versus the ssl socket one):


ClientSocket:

connect():
this->socket = BIO_new_ssl_connect(ssl_context); *
BIO_get_ssl(this->socket, &this->ssl); *
BIO_set_nbio(this->socket, NON_BLOCKING);

BIO_set_conn_hostname(this->socket, this->host);
BIO_set_conn_port(this->socket, port_str);
bool keep_connecting = true;

while (keep_connecting)
{
   if (BIO_do_connect(this->socket) > 0)
   {
if (this->do_verify_handshake_result()) this->connected = true;
keep_connecting = false;
   }
   else if (!BIO_should_retry(this->socket)) keep_connecting = false;
  
}

--

do_verify_handshake_result(): * (just returns true for normal sockets)
bool keep_trying = true;

while (keep_trying)
{
   if (BIO_do_handshake(this->socket) > 0)
   {
   if (SSL_get_verify_result(this->ssl) == X509_V_OK) result = true;
   keep_trying = false;
   }
   else if (!BIO_should_retry(this->socket)) keep_trying = false;
}
--

ServerSocket:
listen():
this->ssl_socket = BIO_new_ssl(ssl_context, SERVER_CONNECTION); *
BIO_get_ssl(this->ssl_socket, &this->ssl); *
this->accept_socket = BIO_new_accept(port_str);
BIO_set_accept_bios(this->accept_socket, this->ssl_socket); *
BIO_set_nbio(this->accept_socket, NON_BLOCKING);
BIO_do_accept(this->accept_socket);

while (!this->shutdown_requested)
{
   if (BIO_do_accept(this->accept_socket) > 0)
   {
   ClientSocket *incoming_client= 
new_client_socket(BIO_pop(this->accept_socket));

   incoming_client->do_verify_handshake_result();
   connection_complete(incoming_client)
   }
}
--
connection_complete(): (this is just a test method)

delete incoming_client;
--
Test code:

typedef struct str_thdata
{
   int thread_no;
  ServerSocket *socket;
} thdata;

void *print_message_function ( void *ptr )
{
   thdata *data = (thdata *) ptr; 
   printf("Thread %d s\n", data->thread_no);fflush(stdout);

   data->socket->listen();
   return NULL;
}

int test()
{
for (int i = 0; i < 200; i++)
   {
   pthread_t thr;
   thdata data;
   data.thread_no = i;
  ServerSocket *socket = SocketFactory::new_server_socket(SSL, 
TEST_PORT);

   data.socket = socket;

   if (pthread_create (&thr, NULL, print_message_function, (void *) 
&data) != 0)
   printf("Warning, create did not work for thread #%d\n", 
i);fflush(stdout);

   else
   {
   Sleep(1000);
   ClientSocket *client = SocketFactory::new_client_socket(SSL, 
(char *) "127.0.0.1", TEST_PORT);


   if (client->connect())
  client->disconnect();
  
   delete client;


   socket->shutdown();
   pthread_join(thr, NULL);
   }


   delete socket;
   }

}

If I use normal server&client sockets, all threads work as expected (can 
create 200). Also, if I use an SSL server, but with no client connecting 
to it (creating a server socket & thread and then closing them 200 
times) - everything works as expected.
If I connect an SSL client socket, no resources after 10-15 threads - I 
can get this to happen reliably. Sometimes I get a few error messages 
and then I can create threads again for a while.


Initially, I had SSL_MODE_AUTO_RETRY set on the server socket (left 
over from when the two classes were using blocking sockets) - removing 
it improved the situation a bit, but not by much (ie before I got thread 
creation errors on each run, now I get them about once for every two runs).


The disconnect/shutdown methods both for client and server just do 
"BIO_free_all(this->socket);", besides setting some bool variables such 
as connected/shutdown_requested. The destructors call 
disconnect/shutdown if sockets are not already closed.


Any ideas on what I'm doing wrong with this? I think I'm neglecting to 
release some resources, but I don't see what could those be - everything 
is closed before each new loop iteration. Setting a "Sleep()" right 
before the loop restarts did not help either.


Thanks in advance,

--
Laura 


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

Re: Verify certificate using subordinate ca

[Serge Fonville]

How do you think compromising a CA would occur, because a CA could
only becom compromised when someone leaks the key for that specific CA
And if it happens once, it will likely happen twice. And I hope in
your best interest, you are not distributing keys to terminals.

Also, if you need to copy a file to 1000^2 terminals, use a script.
I assume you have a list of all these terminals (otherwise you have a
serious problem)

I assume you are using server certificates and client certificates.
with these there corresponds a CRL, this crl can be automatically used
by any clientapplication that uses a certificate issued by any CA

Bacically, are you distributing keys to terminals?

Regards,

Serge Fonville

On Wed, Sep 2, 2009 at 8:21 AM, Yin, Ben 1. (NSN - CN/Cheng
Du) wrote:
> OK, regarding the CA deploy, such as, we have a one root ca and 1000 sub ca 
> signed by root ca. and each sub ca used as ca by 1000 terminals.so the total 
> network size is 1000*1000. All our ca, including root ca and sub ca, was 
> stored offline. I need copy sub ca to terminal it was used. So if one of sub 
> ca was compromised, what I need to do is sign a new sub ca using root ca and 
> copy it to 1000 terminal where sub ca has been compromised. And if root ca 
> was compromised, I need to re-deploy CA on 1000*1000 terminal mannuly. That 
> is why I want to keep root ca out of the chain. And only using sub ca and 
> certificate to do the verification.  Dose it possible? It seems that openssl 
> always try to find the issuer of sub ca during tht chain verification because 
> it wasn't self signed root ca.
>
>
> Br
>
> Ben
>
> -Original Message-
> From: owner-openssl-us...@openssl.org 
> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
> Sent: Tuesday, September 01, 2009 5:14 PM
> To: openssl-users@openssl.org
> Subject: Re: Verify certificate using subordinate ca
>
> I don't see your problem honestly. Figuring out a private key is close
> to impossible.
> And stealing it, well, that is more related to security itself than to
> the actual key being secure or not.
>
> >From what I understand, a chain works somewhat like this
>
> you
> --peter
> john
> --carl
>
> You talk to peter, peter is trusted by john, john is trusted by carl,
> you trust carl
> Say if you were to obsolete carl in this chain (by trusting john) john
> would then become the root
> If this is the case, why would you want to have carl at all?
>
> Thawte, verisign etc work the same way
>
> Also, why is distributing a CA cert so difficult?
> What is your environment?
> What applications are using the certs?
> And how do they verify the chain?
>
> Again, without the key for each CA it can't be compromised
> Has this actually happened or is this someone eing paranoid?
>
> Who has created the chain?
>
> I'm still not clear of the purpose of the root ca if it should not
> need to be trusted
>
> Regards,
>
> Serge Fonville
>
> On Tue, Sep 1, 2009 at 3:52 PM, Yin, Ben 1. (NSN - CN/Cheng
> Du) wrote:
>> No. In our enviroment. The root CA private key is isolated and absolutly 
>> safe. Regarding the compromised, I means CA can't be trusted any more, Such 
>> as the private key was stolen some how or someone find a way to figure out 
>> private key for one CA. it easy to set up new sub ca in one domain if those 
>> compromise happened on sub ca. but if it happened on root ca, it's quite 
>> hard to fix the our whole network. Thanks.
>>
>>
>> Br
>>
>> Ben
>>
>> -Original Message-
>> From: owner-openssl-us...@openssl.org 
>> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
>> Sent: Tuesday, September 01, 2009 4:31 PM
>> To: openssl-users@openssl.org
>> Subject: Re: Verify certificate using subordinate ca
>>
>> Based on what you state.
>> There is no purpose for the root CA.
>>
>> What do you mean by compromised.
>> If you publish a CA certificate to clients, it does not include the
>> key. (normally)
>> So the only thing a client can do is use it in the session at best.
>> There is NO way a client can use a CA certificate to sign anything
>> without the corresponding key.
>>
>> I have a chain on my website, and noone (except me, because I can
>> access the server) is able to sign anything. Since the CAs are only
>> used for signing and verifying and not for encrypting, if the CA keys
>> are stored safely, there is no 'compromise'
>>
>> Are you distributing the keys as well?
>>
>> HTH
>>
>> Regards,
>>
>> Serge Fonville
>>
>>
>> On Tue, Sep 1, 2009 at 2:13 PM, Yin, Ben 1. (NSN - CN/Cheng
>> Du) wrote:
>>> I only want to verfiy the signature (I mean the procedure when sub ca
>>> sign the certiticate). So I guess sub ca and certification should has
>>> enough info to do it because we needn't root ca when we use sub ca to
>>> sign the certificate.  Is there a way for this requirement? Thanks.
>>>
>>>
>>> Br
>>>
>>> Ben
>>>
>>> -Original Message-
>>> From: owner-openssl-us...@openssl.org
>>> [mailto:owner-ope