OpenSSL on Mac
My Mac still has OpenSSL 0.9.8. How may I update this to the latest stable version? I believe the latest stable version is at least 1.0.01
OpenSSL Question, Elliptic Curve Cryptography (ECC) TLS
How do I verify the modulus of an openssl Elliptic Curve Cryptography (ECC) private key? If this were RSA, I would run: openssl x509 -noout -modulus -in certificateFileName.crt | openssl md5 openssl rsa -noout -modulus -in privateKeyFileName.key | openssl md5 openssl req -noout -modulus -in csrFileName.csr | openssl md5 But it's not RSA, so I don't know. I created my private key and CSR by running: openssl ecparam -genkey -text -name secp521r1 -out example-ecc.key openssl req -new -key example-ecc.key -sha256 -out example-ecc.csr
CAVP/DRBG Results with multiple block lengths
I am tasked with running CAVP test vectors for OpenSSL. I have encountered an issue with DRBG and am wondering if anyone has advice. When OpenSSL was originally validated, the DRBG test only required 1 blocksize of output. Now, the default length is 4 blocks unless otherwise requested. I have modified the drbgvs code as follows: r = FIPS_drbg_generate(dctx, randout, randoutlen, 1, adin, adinlen); to r = FIPS_drbg_generate(dctx, randout, numBlocks*blockSize, 1, adin, adinlen); where blockSize is set to the same value as randoutlen, i.e. FIPS_drbg_get_blocklength(dctx); I'm using the DRBG vectors from the CAVP website. The Hash vectors work correctly (excepting SHA-512T, of course), but none of the others do. Here's one test case from HMAC and the results: [SHA-1] [PredictionResistance = True] [EntropyInputLen = 128] [NonceLen = 64] [PersonalizationStringLen = 0] [AdditionalInputLen = 0] [ReturnedBitsLen = 640] COUNT = 0 EntropyInput = a0c9ab58f1e2e5a4de3ebd4ff73e9c5b Nonce = 64efd8ca028cf811 PersonalizationString = AdditionalInput = EntropyInputPR = 48a584fe69ab5aee42aa4d42176099d4 AdditionalInput = EntropyInputPR = 5e1397dc404d86a37bf55954756951e4 ReturnedBits = 17f3656c7e328817dee7ee36d588d72f14514daa 30f71ea20a9687501f4471976f302b636829a6fc 4706b7782fea20d768179d670ccc2e618f1d9727 1128aab2756fe079f3ed92e805515b481f20de2b Results should be: ReturnedBits = 9a00a2d00ed59bfe31ecb1399b608148d1969d25 0d3c1e94101098129325cab8fccc2d54731970c0 107aa4892519955e4bc6001d7f4e6a2bf8a301ab 46055c09a67188f1a740eef3e15c029b44af0344 I would expect that at least the first block length would be correct, but here all bytes are wrong. All results for all test for HMAC, CTR, and DualEC are wrong, but all results for Hash are correct. Can anyone shed some light on why these results are coming back wrong, and how I might remediate them? Is it simply impossible to return correct results when BS1? Thanks, John __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSMTP Client: SSL routines:SSL23_GET_SERVER_HELLO
sorry for the late reply. I was on vacation. Unfortunately, I returned and could not find the managed switch anymore. Someone must've taken it. So I won't be able to post a .pcap file, since I cannot remote capture. However, it seems I managed to get rid of the unknown protocol error. I was using the read function of my colleague and it was only copying bytes until it reaches a newline character, so when I call the TLS function (see the code my 1st post), the receive buffer had already some bytes left over from previous replies. So, as mentioned earlier, I do not get the unknown protocol error anymore, however, ssl_connect still fails but this time it does not print out any error, it simply prints out the following: ///creating TLS Session/ SSL_connect failed I'm trying to connect to smtp.gmail.com:587 Any help will be appreciated. -- View this message in context: http://openssl.6102.n7.nabble.com/SSMTP-Client-SSL-routines-SSL23-GET-SERVER-HELLO-tp48871p49060.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSMTP Client: SSL routines:SSL23_GET_SERVER_HELLO
Just to add more details, here are the replies that my code prints out, when trying to connect to smtp.gmail.com:587 *220 mx.google.com ESMTP x3sm39000551eep.17 - gsmtp //EHLO// 250-mx.google.com at your service, [80.149.109.201] 250-SIZE 35882577 250-8BITMIME 250-STARTTLS 250-ENHANCEDSTATUSCODES 250 CHUNKING //STARTTLS// 220 2.0.0 Ready to start TLS ///creating TLS Session/ SSL_connect failed* -- View this message in context: http://openssl.6102.n7.nabble.com/SSMTP-Client-SSL-routines-SSL23-GET-SERVER-HELLO-tp48871p49061.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] OpenSSL on Mac
Darwinports. -- Erwann ABALEA Le 31/03/2014 21:18, Landen Landens a écrit : My Mac still has OpenSSL 0.9.8. How may I update this to the latest stable version? I believe the latest stable version is at least 1.0.01 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL on Mac
On Mon, Mar 31, 2014 at 3:18 PM, Landen Landens landenfam...@gmail.com wrote: My Mac still has OpenSSL 0.9.8. How may I update this to the latest stable version? You can't because 0.9.8 and 1.0.1 are *not* binary compatible. You can download OpenSSL, `./Configure darwin64-x86_64-cc`, `make`, and then `sudo make install`. Your updated version will be located in `/usr/local/ssl`. Using it in programs can be tricky, though. Apple's linkers do not honor -Bstatic and -rpaths. You will have to compile/link with -I/usr/local/ssl/include and -L/usr/local/ssl/lib. When executing your program linked against your version of OpenSSL, you will need: set env DYLD_INSERT_LIBRARIES /usr/local/ssl/lib/libcrypto.so:/usr/local/ssl/lib/libssl.so DYLD_INSERT_LIBRARIES on OS X is like LD_PRELOAD. If you get obscure errors at odd times, then your 1.0.1 program probably got runtime linking against 0.9.8. If you can get it under the debugger, then issue `info shared` and see what version you actually loaded. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
Hello, I have seen your update. Try Using SSLv3_client_method() instead of SSLv23_client_method(),if you did not try it previously. Refer this Link https://rt.openssl.org/Ticket/Display.html?id=2240user=guestpass=guest Regards Gangadhar -- View this message in context: http://openssl.6102.n7.nabble.com/error-140770FC-SSL-routines-SSL23-GET-SERVER-HELLO-unknown-protocol-tp25096p49067.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: CAVP/DRBG Results with multiple block lengths
On Tue, Apr 01, 2014, John Craft wrote: I am tasked with running CAVP test vectors for OpenSSL. I have encountered an issue with DRBG and am wondering if anyone has advice. Try the fips_drbgvs.c source from the OpenSSL-fips-2_0-dev branch. This determines the required output length by pasring the [ReturnedBitsLen line, if any. 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: OpenSSL Question, Elliptic Curve Cryptography (ECC) TLS
On Mon, Mar 31, 2014 at 01:15:47PM -0600, Landen Landens wrote: How do I verify the modulus of an openssl Elliptic Curve Cryptography (ECC) private key? Elliptic curve keys don't have a modulus, that's a property of RSA keys. If this were RSA, I would run: openssl x509 -noout -modulus -in certificateFileName.crt | openssl md5 openssl rsa -noout -modulus -in privateKeyFileName.key | openssl md5 openssl req -noout -modulus -in csrFileName.csr | openssl md5 Try: openssl x509 -noout -pubkey -in ... | openssl pkey -pubin -outform DER | openssl dgst -sha1 openssl pkey -pubout -outform DER -in ... | openssl dgst -sha1 openssl req -noout -pubkey -in ... | openssl pkey -pubin -outform DER | openssl dgst -sha1 This computes the digest of the DER form of the SubjectPublicKeyInfo (SPKI) of the certificate public key, actual public key and CSR for comparison. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL on Mac
On Tue, Apr 01, 2014 at 05:37:05AM -0400, Jeffrey Walton wrote: You can download OpenSSL, `./Configure darwin64-x86_64-cc`, `make`, and then `sudo make install`. Your updated version will be located in `/usr/local/ssl`. Using it in programs can be tricky, though. Apple's linkers do not honor -Bstatic and -rpaths. You will have to compile/link with -I/usr/local/ssl/include and -L/usr/local/ssl/lib. However, alternative flags that achieve the same effect are available: To build a library whose SONAME involves an rpath: $ cc -shared -Wl,-flat_namespace -Wl,-undefined,dynamic_lookup \ -Wl,-install_name,@rpath/libfoo.dylib.1 -o libfoo.dylib.1 # cp libfoo.dylib.1 /usr/local/lib # ln -s libfoo.dylib.1 /usr/local/lib/libfoo To build an executable that uses this library: cc -Wl,-rpath,/usr/local/lib -L/usr/local/lib -lfoo Then no kludgey DYLD_ environment variables are required at runtime. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: where are key usages checked?
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Bin Lu
Sent: Monday, 31 March, 2014 16:34
During SSL handshake with client cert auth, is openssl checking the key
usages,
such as digital signature, non-repudiation etc, for the client cert passed in
(to
make sure it is a valid client cert)? If it is, where is the code that does
it? I
cannot find it in X509_verify_cert().
Look at crypto/x509v3/v3_purp.c. In 1.0.1c, check_purpose_ssl_client() has a
couple of key-usage checks, for example:
-
static int check_purpose_ssl_client(const X509_PURPOSE *xp, const X509 *x, int
ca)
{
if(xku_reject(x,XKU_SSL_CLIENT)) return 0;
if(ca) return check_ssl_ca(x);
/* We need to do digital signatures with it */
if(ku_reject(x,KU_DIGITAL_SIGNATURE)) return 0;
/* nsCertType if present should allow SSL client use */
if(ns_reject(x, NS_SSL_CLIENT)) return 0;
return 1;
}
-
ku_reject tests the regular key usage, and xku_reject tests the extended key
usage, if the certificate includes the appropriate extension.
I haven't actually stepped through the code in question, but it appears to be
what you're looking for.
--
Michael Wojcik
Technology Specialist, Micro Focus
This message has been scanned for malware by Websense. www.websense.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: OpenSSL on Mac
On Tue, Apr 1, 2014 at 9:24 AM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Tue, Apr 01, 2014 at 05:37:05AM -0400, Jeffrey Walton wrote: You can download OpenSSL, `./Configure darwin64-x86_64-cc`, `make`, and then `sudo make install`. Your updated version will be located in `/usr/local/ssl`. Using it in programs can be tricky, though. Apple's linkers do not honor -Bstatic and -rpaths. You will have to compile/link with -I/usr/local/ssl/include and -L/usr/local/ssl/lib. However, alternative flags that achieve the same effect are available: To build a library whose SONAME involves an rpath: $ cc -shared -Wl,-flat_namespace -Wl,-undefined,dynamic_lookup \ -Wl,-install_name,@rpath/libfoo.dylib.1 -o libfoo.dylib.1 # cp libfoo.dylib.1 /usr/local/lib # ln -s libfoo.dylib.1 /usr/local/lib/libfoo To build an executable that uses this library: cc -Wl,-rpath,/usr/local/lib -L/usr/local/lib -lfoo I have not had success with the above (-Wl,-rpath,/usr/local/lib) with shared objects. But I'm pretty sure they all have had the extension *.so. Does the Apple linker honor it if the extension is *.dylib? Do you have any tricks for -Bstatic? Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL on Mac
On Tue, Apr 01, 2014 at 10:01:16AM -0400, Jeffrey Walton wrote: However, alternative flags that achieve the same effect are available: To build a library whose SONAME involves an rpath: $ cc -shared -Wl,-flat_namespace -Wl,-undefined,dynamic_lookup \ -Wl,-install_name,@rpath/libfoo.dylib.1 -o libfoo.dylib.1 # cp libfoo.dylib.1 /usr/local/lib # ln -s libfoo.dylib.1 /usr/local/lib/libfoo To build an executable that uses this library: cc -Wl,-rpath,/usr/local/lib -L/usr/local/lib -lfoo I have not had success with the above (-Wl,-rpath,/usr/local/lib) with shared objects. But I'm pretty sure they all have had the extension *.so. Does the Apple linker honor it if the extension is *.dylib? The extension is not the point, to use rpaths the SONAME (install_name when building the shared object) of the target library has to start with @rpath/. The extension of the filename after @rpath/ is not important: @rpath/libfoo.so.1 will work just as well as: @rpath/libfoo.dylib.1 provided the object is installed with the name in question. However, to link with -lfoo, there should be a symlink: libfoo.dylib - libfoo.dylib.1 | libfoo.so.1 pointing to whichever form is used for the SONAME. The compiler flags are somewhat release dependent. My tests are with MacOSX 10.9 (Mavericks). Sufficiently older releases will require different flags. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL FIPS Object Module 2.0 update
This is the promised update to my message of February 4. As before, if you don't know what FIPS 140-2 is then ignore this and count yourself lucky. Effective Jan 1 some new FIPS 140-2 validation requirements were introduced that failed to take into consideration the impact on change letter updates to existing validations. As a consequence we have been unable to proceed with the addition of platforms to the #1747 validation, aka the OpenSSL FIPS Object Module 2.0. I am pleased to report that after three months the CMVP has finally issued the guidance that allows us to proceed with change letter updates to the #1747 validation. We currently have eleven platforms in-house and are working the formal testing process for those as expeditiously as possible. Those will appear as revision 2.0.7. On January 20 we submitted the formal paperwork for approval of revision 2.0.6 to the OpenSSL FIPS Object Module 2.0 to completely remove the Dual EC DRBG implementation. I am informed that submission is under review but have no idea if or when approval can be expected, so the revision 2.0.7 testing is proceeding with the Dual EC DRBG code in place. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
openssl-1.0.1e client - fatal alert: Protocol Version (70) at Server Hello
Hello OpenSSL gurus,
I found in my sendmail-8.14.7/Fedora-18-i386 queue undelivered mails,
log say 'TLS handshake failed', and when I captured traffic between
mine and destination mailserver, I got result as in attached text export
from wireshark.
And when I tried:
openssl s_client -starttls smtp -connect DestMTA -msg -debug
, I will get some as:
...
TLS 1.2 Handshake [length 00f4], ClientHello
01 00 00 f0 03 03 53 3a d1 72 61 e9 9f c9 ce dc
97 e0 5d ed 70 b4 2e b5 b2 6c f0 b6 73 28 bf a3
21 6c d0 a7 cc dc 00 00 84 c0 30 c0 2c c0 28 c0
24 c0 14 c0 0a 00 a3 00 9f 00 6b 00 6a 00 39 00
38 00 88 00 87 c0 32 c0 2e c0 2a c0 26 c0 0f c0
05 00 9d 00 3d 00 35 00 84 c0 12 c0 08 00 16 00
13 c0 0d c0 03 00 0a c0 2f c0 2b c0 27 c0 23 c0
13 c0 09 00 a2 00 9e 00 67 00 40 00 33 00 32 00
9a 00 99 00 45 00 44 c0 31 c0 2d c0 29 c0 25 c0
0e c0 04 00 9c 00 3c 00 2f 00 96 00 41 00 07 c0
11 c0 07 c0 0c c0 02 00 05 00 04 00 ff 01 00 00
43 00 0b 00 04 03 00 01 02 00 0a 00 08 00 06 00
19 00 18 00 17 00 23 00 00 00 0d 00 22 00 20 06
01 06 02 06 03 05 01 05 02 05 03 04 01 04 02 04
03 03 01 03 02 03 03 02 01 02 02 02 03 01 01 00
0f 00 01 01
read from 0x8fd44e0 [0x8fdb340] (7 bytes = 7 (0x7))
- 16 03 02 00 3a 02 :.
0007 - SPACES/NULS
read from 0x8fd44e0 [0x8fdb34a] (56 bytes = 56 (0x38))
- 00 36 03 03 53 3a d1 72-0c 7c 8d 9e 5b ba 26 71 .6..S:.r.|..[.q
0010 - 26 87 fd b1 ec c6 fe 4d-ee 4f d3 03 31 ea f9 2e ..M.O..1...
0020 - 5e 54 fd b8 00 00 9d 00-00 0e ff 01 00 01 00 00 ^T..
0030 - 23 00 00 00 0f 00 01 01- #...
TLS 1.1 Handshake [length 003a], ServerHello
02 00 00 36 03 03 53 3a d1 72 0c 7c 8d 9e 5b ba
26 71 26 87 fd b1 ec c6 fe 4d ee 4f d3 03 31 ea
f9 2e 5e 54 fd b8 00 00 9d 00 00 0e ff 01 00 01
00 00 23 00 00 00 0f 00 01 01
write to 0x8fd44e0 [0x8fe4d50] (7 bytes = 7 (0x7))
- 15 03 03 00 02 02 46 ..F
TLS 1.2 Alert [length 0002], fatal protocol_version
02 46
3070990124:error:1409210A:SSL routines:SSL3_GET_SERVER_HELLO:wrong ssl
version:s3_clnt.c:869:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 297 bytes and written 7 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.1
Cipher:
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1396363634
Timeout : 300 (sec)
Verify return code: 0 (ok)
which is perhaps same error. On mentioned 's3_clnt.c' line is code:
d=p=(unsigned char *)s-init_msg;
if ((p[0] != (s-version8)) || (p[1] != (s-version0xff)))
{
SSLerr(SSL_F_SSL3_GET_SERVER_HELLO,SSL_R_WRONG_SSL_VERSION);
s-version=(s-version0xff00)|p[1];
al=SSL_AD_PROTOCOL_VERSION;
goto f_err;
}
As I'm not programmer, I was not able tracking it more closely, only
I suspect that one version values may be the record layer version
number (0x0302 ~ TLS 1.1) and other may be Server Hello version values
(0x0303 ~ TLS 1.2). But according to e.g. this article:
http://security.stackexchange.com/questions/29314/what-is-the-significance-of-the-version-field-in-a-tls-1-1-clienthello-message
, I cite:
...
The response from the server states the protocol version which will be
used, and should come as records bearing that version. E.g. if the server
says TLS 1.1 in its ServerHello then that ServerHello should come
wrapped into a record also tagged as TLS 1.1; and all subsequent records
from both client and server should use that version.
...
these values _SHOULD_ be same, but I nowhere found that _MUST_ be same.
Thus, I not know, when is problem on remote server side, or in my
sendmail with openssl-1.0.1e.
Can, please, anyone advise what the problem is, and if so, whether
it can be solved on my side?
TIA, Franta Hanzlik
...
No. TimeSourceDestination Protocol Info
4 10.836313 89.24.112.34 85.13.84.100 SMTP S: 220
elfetex.cz Kerio Connect 8.2.2 ESMTP ready
Frame 4: 114 bytes on wire (912 bits), 114 bytes captured (912 bits)
Ethernet II, Src: Routerbo_78:ac:ba (00:0c:42:78:ac:ba), Dst: Intel_bb:7f:e3
(00:02:b3:bb:7f:e3)
Internet Protocol Version 4, Src: 89.24.112.34 (89.24.112.34), Dst:
85.13.84.100 (85.13.84.100)
Transmission Control Protocol, Src Port: 25 (25), Dst Port: 52187 (52187), Seq:
1, Ack: 1, Len: 48
Simple Mail Transfer Protocol
Response: 220 elfetex.cz Kerio Connect 8.2.2 ESMTP ready\r\n
Response code: domain Service ready (220)
Response parameter: elfetex.cz Kerio Connect 8.2.2 ESMTP ready
...
No. TimeSourceDestination Protocol Info
6 10.836414 85.13.84.100
RE: where are key usages checked?
That is what I guessed, but I could not figure out the execution path from
X509_verify_cert() to this call. Actually I could not find out how
ctx-param-purpose in check_chain_extensions() is set which leads to call
X509_check_purpose().
By the way, shouldn't checking on 'ca' be called before xku checking in
check_purpose_ssl_client()?
Thanks,
-binlu
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Michael Wojcik
Sent: Tuesday, April 01, 2014 6:28 AM
To: openssl-users@openssl.org
Subject: RE: where are key usages checked?
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Bin Lu
Sent: Monday, 31 March, 2014 16:34
During SSL handshake with client cert auth, is openssl checking the
key usages, such as digital signature, non-repudiation etc, for the
client cert passed in (to make sure it is a valid client cert)? If it
is, where is the code that does it? I cannot find it in X509_verify_cert().
Look at crypto/x509v3/v3_purp.c. In 1.0.1c, check_purpose_ssl_client() has a
couple of key-usage checks, for example:
-
static int check_purpose_ssl_client(const X509_PURPOSE *xp, const X509 *x, int
ca) {
if(xku_reject(x,XKU_SSL_CLIENT)) return 0;
if(ca) return check_ssl_ca(x);
/* We need to do digital signatures with it */
if(ku_reject(x,KU_DIGITAL_SIGNATURE)) return 0;
/* nsCertType if present should allow SSL client use */
if(ns_reject(x, NS_SSL_CLIENT)) return 0;
return 1;
}
-
ku_reject tests the regular key usage, and xku_reject tests the extended key
usage, if the certificate includes the appropriate extension.
I haven't actually stepped through the code in question, but it appears to be
what you're looking for.
--
Michael Wojcik
Technology Specialist, Micro Focus
This message has been scanned for malware by Websense. www.websense.com
__
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
