Question about intermediate certificate chain

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about intermediate certificate chain

Jorge Ventura
I have an application (server) that is working using SSLv23 with a
regular certificate. Now I have to use one chain of two intermediate
certificates but for any reason, openssl library is not sending the
chain and the only way to work correctly is when I inform to the
client side about the intermediate.

If I am understanding correctly, as long as the client trust in the
last certificate, it will trust on all intermediate.

Below is a result using the command "openssl s_client ...".

The client has only the Equifax root certificate; all other GeoTrust
are intermediate. The file cacerts.pem in the command below has the
two intermediate informed to force the command to succeed but in the
real case, I don't have such information at client side.

Because the client trust the connection when I inform the
intermediate, I suppose the server is not sending the intermediate,
only the first certificate in the chain and in this case the command
fail.


$ openssl s_client -connect 10.10.10.10:443 -verify 5 -state -CAfile cacerts.pem
verify depth is 5
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=3 /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
verify return:1
depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
verify return:1
depth=1 /C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
verify return:1
depth=0 /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
Lake/O=ACME, INC/CN=www.acme.com
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
CONNECTED(00000003)
---
Certificate chain
 0 s:/serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
Lake/O=ACME, INC/CN=www.acme.com
   i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
---
Server certificate
-----BEGIN CERTIFICATE-----
    (the server certificate)
-----END CERTIFICATE-----
subject=/serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
Lake/O=ACME, INC/CN=www.acme.com
issuer=/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
---
No client certificate CA names sent
---
SSL handshake has read 1539 bytes and written 447 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: 5FB55650BEEAE091441A5CEF4047A0243EE9D57AE8F0485CC1F951E2E97CAE06
    Session-ID-ctx:
    Master-Key:
06B036B9D47B297D2086CB6370108BB60102CD0FD7649F92351E15324D96E8614C566BF9040296177E2BDCA0A189472C
    Key-Arg   : None
    Start Time: 1369178367
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
read:errno=0
SSL3 alert write:warning:close notify
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Question about intermediate certificate chain

Wim Lewis-3

On 21 May 2013, at 5:02 PM, Jorge Ventura wrote:
> Because the client trust the connection when I inform the
> intermediate, I suppose the server is not sending the intermediate,
> only the first certificate in the chain and in this case the command
> fail.

That is a reasonable conclusion. You can check for sure using the "-showcerts" option to openssl s_client.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Question about intermediate certificate chain

Somesh Chakrabarti
In reply to this post by Jorge Ventura
Jorge,

On the server, you can copy all the public certs i.e. the intermediates and the root into one PEM file. That will send everything down to the client.

Best,
Somesh

On Tuesday, May 21, 2013, Jorge Ventura wrote:
I have an application (server) that is working using SSLv23 with a
regular certificate. Now I have to use one chain of two intermediate
certificates but for any reason, openssl library is not sending the
chain and the only way to work correctly is when I inform to the
client side about the intermediate.

If I am understanding correctly, as long as the client trust in the
last certificate, it will trust on all intermediate.

Below is a result using the command "openssl s_client ...".

The client has only the Equifax root certificate; all other GeoTrust
are intermediate. The file cacerts.pem in the command below has the
two intermediate informed to force the command to succeed but in the
real case, I don't have such information at client side.

Because the client trust the connection when I inform the
intermediate, I suppose the server is not sending the intermediate,
only the first certificate in the chain and in this case the command
fail.


$ openssl s_client -connect 10.10.10.10:443 -verify 5 -state -CAfile cacerts.pem
verify depth is 5
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=3 /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
verify return:1
depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
verify return:1
depth=1 /C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
verify return:1
depth=0 /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
Lake/O=ACME, INC/CN=www.acme.com
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
CONNECTED(00000003)
---
Certificate chain
 0 s:/serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
Lake/O=ACME, INC/CN=www.acme.com
   i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
---
Server certificate
-----BEGIN CERTIFICATE-----
    (the server certificate)
-----END CERTIFICATE-----
subject=/serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
Lake/O=ACME, INC/CN=www.acme.com
issuer=/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
---
No client certificate CA names sent
---
SSL handshake has read 1539 bytes and written 447 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: 5FB55650BEEAE091441A5CEF4047A0243EE9D57AE8F0485CC1F951E2E97CAE06
    Session-ID-ctx:
    Master-Key:
06B036B9D47B297D2086CB6370108BB60102CD0FD7649F92351E15324D96E8614C566BF9040296177E2BDCA0A189472C
    Key-Arg   : None
    Start Time: 1369178367
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
read:errno=0
SSL3 alert write:warning:close notify
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;openssl-users@openssl.org&#39;)">openssl-users@...
Automated List Manager                           <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;majordomo@openssl.org&#39;)">majordomo@...
Reply | Threaded
Open this post in threaded view
|

Re: Question about intermediate certificate chain

Jorge Ventura
Somech,
The server side is using one .pem file like this:

<private key>
<the certificate>
<intermediate 1>
<intermediate 2>

The <intermediate 2> was signed by one root CA available at client
side and the two intermediate was supplied by the same root authority.
I think that I didn't forgot that.





On Tue, May 21, 2013 at 7:29 PM, Somesh Chakrabarti
<[hidden email]> wrote:

> Jorge,
>
> On the server, you can copy all the public certs i.e. the intermediates and
> the root into one PEM file. That will send everything down to the client.
>
> Best,
> Somesh
>
>
> On Tuesday, May 21, 2013, Jorge Ventura wrote:
>>
>> I have an application (server) that is working using SSLv23 with a
>> regular certificate. Now I have to use one chain of two intermediate
>> certificates but for any reason, openssl library is not sending the
>> chain and the only way to work correctly is when I inform to the
>> client side about the intermediate.
>>
>> If I am understanding correctly, as long as the client trust in the
>> last certificate, it will trust on all intermediate.
>>
>> Below is a result using the command "openssl s_client ...".
>>
>> The client has only the Equifax root certificate; all other GeoTrust
>> are intermediate. The file cacerts.pem in the command below has the
>> two intermediate informed to force the command to succeed but in the
>> real case, I don't have such information at client side.
>>
>> Because the client trust the connection when I inform the
>> intermediate, I suppose the server is not sending the intermediate,
>> only the first certificate in the chain and in this case the command
>> fail.
>>
>>
>> $ openssl s_client -connect 10.10.10.10:443 -verify 5 -state -CAfile
>> cacerts.pem
>> verify depth is 5
>> SSL_connect:before/connect initialization
>> SSL_connect:SSLv2/v3 write client hello A
>> SSL_connect:SSLv3 read server hello A
>> depth=3 /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
>> verify return:1
>> depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
>> verify return:1
>> depth=1 /C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
>> verify return:1
>> depth=0
>> /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
>> Lake/O=ACME, INC/CN=www.acme.com
>> verify return:1
>> SSL_connect:SSLv3 read server certificate A
>> SSL_connect:SSLv3 read server done A
>> SSL_connect:SSLv3 write client key exchange A
>> SSL_connect:SSLv3 write change cipher spec A
>> SSL_connect:SSLv3 write finished A
>> SSL_connect:SSLv3 flush data
>> SSL_connect:SSLv3 read finished A
>> CONNECTED(00000003)
>> ---
>> Certificate chain
>>  0
>> s:/serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
>> Lake/O=ACME, INC/CN=www.acme.com
>>    i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
>> ---
>> Server certificate
>> -----BEGIN CERTIFICATE-----
>>     (the server certificate)
>> -----END CERTIFICATE-----
>>
>> subject=/serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
>> Lake/O=ACME, INC/CN=www.acme.com
>> issuer=/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
>> ---
>> No client certificate CA names sent
>> ---
>> SSL handshake has read 1539 bytes and written 447 bytes
>> ---
>> New, TLSv1/SSLv3, Cipher is AES256-SHA
>> Server public key is 2048 bit
>> Secure Renegotiation IS supported
>> Compression: NONE
>> Expansion: NONE
>> SSL-Session:
>>     Protocol  : TLSv1
>>     Cipher    : AES256-SHA
>>     Session-ID:
>> 5FB55650BEEAE091441A5CEF4047A0243EE9D57AE8F0485CC1F951E2E97CAE06
>>     Session-ID-ctx:
>>     Master-Key:
>>
>> 06B036B9D47B297D2086CB6370108BB60102CD0FD7649F92351E15324D96E8614C566BF9040296177E2BDCA0A189472C
>>     Key-Arg   : None
>>     Start Time: 1369178367
>>     Timeout   : 300 (sec)
>>     Verify return code: 0 (ok)
>> ---
>> read:errno=0
>> SSL3 alert write:warning:close notify
>> ______________________________________________________________________
>> OpenSSL Project                                 http://www.openssl.org
>> User Support Mailing List                    [hidden email]
>> Automated List Manager                           [hidden email]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Question about intermediate certificate chain

Wim Lewis-3

On 21 May 2013, at 5:37 PM, Jorge Ventura wrote:

> Somech,
> The server side is using one .pem file like this:
>
> <private key>
> <the certificate>
> <intermediate 1>
> <intermediate 2>
>
> The <intermediate 2> was signed by one root CA available at client
> side and the two intermediate was supplied by the same root authority.
> I think that I didn't forgot that.


It depends on the server, but with Apache for example, I think you need to explicitly specify SSLCertificateChainFile, even if that same file is also specified using SSLCertificateFile.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Question about intermediate certificate chain

Jorge Ventura
In reply to this post by Wim Lewis-3
That is what I have when I don't include the intermediate in the command:

openssl s_client -connect 10.10.10.10:443 -verify 5 -state -showcerts
verify depth is 5
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=0 /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
Lake/O=ACME, INC/CN=www.acme.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
Lake/O=ACME, INC/CN=www.acme.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
Lake/O=ACME, INC/CN=www.acme.com
verify error:num=21:unable to verify the first certificate
verify return:1

And this one when I include the two intermediate at cacerts.pem.

openssl s_client -connect 10.10.10.10:443 -verify 5 -CAfile
cacerts.pem -showcerts
verify depth is 5
CONNECTED(00000003)
depth=3 /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
verify return:1
depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
verify return:1
depth=1 /C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
verify return:1
depth=0 /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
Lake/O=ACME, INC/CN=www.acme.com
verify return:1
---
Certificate chain
 0 s:/serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
Lake/O=ACME, INC/CN=www.acme.com
   i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA



On Tue, May 21, 2013 at 7:26 PM, Wim Lewis <[hidden email]> wrote:

>
> On 21 May 2013, at 5:02 PM, Jorge Ventura wrote:
>> Because the client trust the connection when I inform the
>> intermediate, I suppose the server is not sending the intermediate,
>> only the first certificate in the chain and in this case the command
>> fail.
>
> That is a reasonable conclusion. You can check for sure using the "-showcerts" option to openssl s_client.
>
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Question about intermediate certificate chain

Somesh Chakrabarti
In your s_client command, you still need to include the -CAfile parameter and point it to just the self-signed Root certificate. Your server is sending the intermediates but the client is not able to verify the chain up to a Root.

You may want to edit cacerts.pem to include only the Root certificate and try again.


On Tue, May 21, 2013 at 5:50 PM, Jorge Ventura <[hidden email]> wrote:
That is what I have when I don't include the intermediate in the command:

openssl s_client -connect 10.10.10.10:443 -verify 5 -state -showcerts
verify depth is 5
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=0 /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
Lake/O=ACME, INC/CN=www.acme.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
Lake/O=ACME, INC/CN=www.acme.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
Lake/O=ACME, INC/CN=www.acme.com
verify error:num=21:unable to verify the first certificate
verify return:1

And this one when I include the two intermediate at cacerts.pem.

openssl s_client -connect 10.10.10.10:443 -verify 5 -CAfile
cacerts.pem -showcerts
verify depth is 5
CONNECTED(00000003)
depth=3 /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
verify return:1
depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
verify return:1
depth=1 /C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
verify return:1
depth=0 /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
Lake/O=ACME, INC/CN=www.acme.com
verify return:1
---
Certificate chain
 0 s:/serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
Lake/O=ACME, INC/CN=www.acme.com
   i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA



On Tue, May 21, 2013 at 7:26 PM, Wim Lewis <[hidden email]> wrote:
>
> On 21 May 2013, at 5:02 PM, Jorge Ventura wrote:
>> Because the client trust the connection when I inform the
>> intermediate, I suppose the server is not sending the intermediate,
>> only the first certificate in the chain and in this case the command
>> fail.
>
> That is a reasonable conclusion. You can check for sure using the "-showcerts" option to openssl s_client.
>
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Question about intermediate certificate chain

Peter Sandelin
Please note that s_client is used for debugging connections not certs
and might connect EVEN IF the server certificate is not good.

http://www.openssl.org/docs/apps/s_client.html#item__verify
"Currently the verify operation continues after errors so all the
problems with a certificate chain can be seen. As a side effect the
connection will never fail due to a server certificate verify
failure."

For checking your certificate chains I recommend OpenSSL's "verify" command.
http://www.openssl.org/docs/apps/verify.html

P

On 22 May 2013 03:06, Somesh Chakrabarti <[hidden email]> wrote:

> In your s_client command, you still need to include the -CAfile parameter
> and point it to just the self-signed Root certificate. Your server is
> sending the intermediates but the client is not able to verify the chain up
> to a Root.
>
> You may want to edit cacerts.pem to include only the Root certificate and
> try again.
>
>
> On Tue, May 21, 2013 at 5:50 PM, Jorge Ventura
> <[hidden email]> wrote:
>>
>> That is what I have when I don't include the intermediate in the command:
>>
>> openssl s_client -connect 10.10.10.10:443 -verify 5 -state -showcerts
>> verify depth is 5
>> CONNECTED(00000003)
>> SSL_connect:before/connect initialization
>> SSL_connect:SSLv2/v3 write client hello A
>> SSL_connect:SSLv3 read server hello A
>> depth=0
>> /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
>> Lake/O=ACME, INC/CN=www.acme.com
>> verify error:num=20:unable to get local issuer certificate
>> verify return:1
>> depth=0
>> /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
>> Lake/O=ACME, INC/CN=www.acme.com
>> verify error:num=27:certificate not trusted
>> verify return:1
>> depth=0
>> /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
>> Lake/O=ACME, INC/CN=www.acme.com
>> verify error:num=21:unable to verify the first certificate
>> verify return:1
>>
>> And this one when I include the two intermediate at cacerts.pem.
>>
>> openssl s_client -connect 10.10.10.10:443 -verify 5 -CAfile
>> cacerts.pem -showcerts
>> verify depth is 5
>> CONNECTED(00000003)
>> depth=3 /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
>> verify return:1
>> depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
>> verify return:1
>> depth=1 /C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
>> verify return:1
>> depth=0
>> /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
>> Lake/O=ACME, INC/CN=www.acme.com
>> verify return:1
>> ---
>> Certificate chain
>>  0
>> s:/serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
>> Lake/O=ACME, INC/CN=www.acme.com
>>    i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
>>
>>
>>
>> On Tue, May 21, 2013 at 7:26 PM, Wim Lewis <[hidden email]> wrote:
>> >
>> > On 21 May 2013, at 5:02 PM, Jorge Ventura wrote:
>> >> Because the client trust the connection when I inform the
>> >> intermediate, I suppose the server is not sending the intermediate,
>> >> only the first certificate in the chain and in this case the command
>> >> fail.
>> >
>> > That is a reasonable conclusion. You can check for sure using the
>> > "-showcerts" option to openssl s_client.
>> >
>> >
>> > ______________________________________________________________________
>> > OpenSSL Project                                 http://www.openssl.org
>> > User Support Mailing List                    [hidden email]
>> > Automated List Manager                           [hidden email]
>> ______________________________________________________________________
>> OpenSSL Project                                 http://www.openssl.org
>> User Support Mailing List                    [hidden email]
>> Automated List Manager                           [hidden email]
>
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]