Issue with SSL sockets pthreads
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 serverclient 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.org
Re: blocking BIO_read
Thank you very much!
Ger Hobbelt wrote:
On Thu, Aug 27, 2009 at 2:24 PM, Laura
Arhirelaura.arh...@endion-software.com wrote:
Hey
I'm using the BIO abstraction for reading/writing to sockets - a small part
of the BIO_read method is unclear: For a blocking socket, will the BIO_read
call block until the length provided in the call is filled in the buffer,
or will it return as soon as it managed to read anything from the socket?
I see that the underlying implementation uses recv() - recv blocks until
something is available: when something is available for reading, read up to
len bytes and copy it to the provided buffer, then return, i.e. the length
is used as a maximum value. From reading the openssl code I think that
BIO_read behaves in the same way as recv - which means that if I want to
read a specific number of bytes (no more, no less), I need to loop until I
get everything I need. Can anyone confirm this ?
Confirmed.
BIO_read won't wait/guarantee that the requested number of bytes are
delivered all, so you'll indeed need to loop to get them all (or an
error due to connection issues) if you want to receive a predetermined
number of bytes.
For completeness / additive: note that 'officially', you should check
the BIO_should_retry() call on error (negative error code return),
i.e.
---snip[stripped]---
...
i = BIO_read(bio,buf,bufsize);
if (i 0)
{
// error condition - possibly
if (BIO_should_retry(bio))
{
if (BIO_should_read(bio))
...
if (BIO_should_write(bio))
...
}
else
{
// real error. process the error the way you want/need
ERR_print_errors(bio_err);
got fail_dramatically;
}
}
else if (i == 0)
{
// blocking -- conn termination
...
break;
}
else
{
// collect the returned bytes; shift buf, etc., then wait for the rest
...
}
---snip---
as this is what it should look like for any and all BIOs, i.e. when
your BIO-using code layer should not be specifically aware of the
chain/device peculiarities accessed through the BIO abstraction layer.
In the case of raw socket I/O, the 'should_retry' won't fire, at least
not with the current implementation on UNIX. Which might be a bother
regarding testability versus 'correct' use/implementation of the i/o
abstraction. Once you're stacking, say, and SSL BIO into this BIO
chain however, things will certainly look /very/ different and you'll
surely need that should_retry/etc. code in there.
Take care,
Ger
--
Laura
blocking BIO_read
Hey I'm using the BIO abstraction for reading/writing to sockets - a small part of the BIO_read method is unclear: For a blocking socket, will the BIO_read call block until the length provided in the call is filled in the buffer, or will it return as soon as it managed to read anything from the socket? I see that the underlying implementation uses recv() - recv blocks until something is available: when something is available for reading, read up to len bytes and copy it to the provided buffer, then return, i.e. the length is used as a maximum value. From reading the openssl code I think that BIO_read behaves in the same way as recv - which means that if I want to read a specific number of bytes (no more, no less), I need to loop until I get everything I need. Can anyone confirm this ? Thank you, -- Laura __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: ecdsa public key output
Hello
I generated the certificate programmatically, but I shall look at the
ecparam.c file and see how the public key is generated there and do the
same. The jave keytool-generated certificate did not have any extensions
attached, so I am guessing those can be stripped.
The code I used for generating a self-signed certificate is below,
stripped of error handling:
EC_KEY *ec_key = EC_KEY_new_by_curve_name(NID_secp160r1);
EC_KEY_generate_key(ec_key);
EC_KEY_check_key(ec_key);
EVP_PKEY *pk = EVP_PKEY_new();
EVP_PKEY_assign_EC_KEY(pk, ec_key);
f = fopen(root-ecdsa160.key, w);
PEM_write_PrivateKey(f, pk, NULL, NULL, 0, 0, NULL);
fclose(f);
FILE *f;
X509 *x;
x=X509_new();
X509_NAME *name = X509_get_subject_name(x);
X509_set_version(x, 2);
ASN1_INTEGER_set(X509_get_serialNumber(x), 3);
X509_gmtime_adj(X509_get_notBefore(x), 0);
X509_gmtime_adj(X509_get_notAfter(x), (long) 60 * 60 * 24 * 365);
X509_set_pubkey(x, pk);
X509_NAME_add_entry_by_txt(name, CN, MBSTRING_ASC, (const unsigned
char*) Testing Team, -1, -1, 0);
X509_NAME_add_entry_by_txt(name, O, MBSTRING_ASC, (const unsigned
char*) client, -1, -1, 0);
X509_set_issuer_name(x, name);
X509_sign(x, pk, EVP_ecdsa());
f = fopen(root-ecdsa160.crt, w);
PEM_write_X509(f, x);
fclose(f);
Thank you for the help.
Laura
Carlo Milono wrote:
How did you make your EC certificates?
Here is the result (truncated as yours is) by using OpenSSL - I had to
use a Name Constraint and a prime curve @ 384 for a proof-of-concept:
...
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
EC Public Key:
pub:
04:fa:b7:e7:c8:15:0b:26:5c:b4:d6:53:62:09:66:
7e:6e:15:05:ee:cc:2b:ff:f9:dd:8d:4f:ed:de:35:
56:41:ce:b4:52:4e:c5:99:46:30:b7:81:31:29:cd:
5f:0d:b9:a3:ec:12:c5:47:f1:0b:09:1c:76:fe:e5:
e2:d3:04:97:3c:ac:ad:b6:e8:83:8b:b0:c2:39:ac:
8e:a2:86:59:a0:0b:0a:09:b1:75:5b:2e:83:b6:7e:
c0:ad:8f:24:54:d4:9a
ASN1 OID: secp384r1
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Name Constraints:
Excluded:
IP:10.105.150.234/255.255.254.0
...
The above is the result of the following command-lines:
openssl ecparam -out myECkey.pem -name secp384r1 -genkey
openssl req -new -key myECkey.pem -out req.out
-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Laura Arhire
Sent: Tuesday, August 18, 2009 12:55 AM
To: openssl-users@openssl.org
Subject: ecdsa public key output
Hello
I'm trying to import ecdsa certificates for a java server using the java
keytool utility. After having had trouble with openssl generated
certificates, I generated a certificate using the keytool utility to see
what the difference is. Upon running the openssl x509 -in cert.crt
-noout -text command on this certificate, the output I get is (only
public key info for brevity):
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
EC Public Key:
pub:
04:99:cc:aa:5b:7d:fc:e1:aa:c8:0e:d0:98:b2:ed:
79:65:cb:66:7e:0f:c2:b9:7b:28:42:1b:65:1a:86:
4b:02:dc:7c:5f:d1:21:1f:ca:f2:ac
* ASN1 OID: secp160k1*
Which is different from the openssl generated certificates in that it
has the curve name in the public key, instead of the curve parameters.
The same data (ASN1 OID: secp160k1) in an openssl certificate is:
Field Type: prime-field
Prime:
00:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
ff:fe:ff:ff:ac:73
A:0
B:7 (0x7)
Generator (uncompressed):
04:3b:4c:38:2c:e3:7a:a1:92:a4:01:9e:76:30:36:
f4:f5:dd:4d:7e:bb:93:8c:f9:35:31:8f:dc:ed:6b:
c2:82:86:53:17:33:c3:f0:3c:4f:ee
Order:
01:00:00:00:00:00:00:00:00:00:01:b8:fa:16:df:
ab:9a:ca:16:b6:b3
Cofactor: 1 (0x1)
The keytool output does not seem to be incorrect according to RFC 5280,
which defines
SubjectPublicKeyInfo ::= SEQUENCE {
algoritmAlgorithmIdentifier
subjectPublicKey BIT STRING
}
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL }
unless I am reading this wrong, but the way algorithm parameters are
defined seem to allow for both variants.
I'm looking into making the java certificate store understand
openssl-generated certificates (possibly with 3rd party APIs) as that
would make my life easier.
However, at the same time I'm trying to tackle the problem at the other
end, so I was also wondering if I can get (maybe programatically ?),
openssl to output the public key info in the way in which the keytool
understands
ecdsa public key output
Hello
I'm trying to import ecdsa certificates for a java server using the java
keytool utility. After having had trouble with openssl generated
certificates, I generated a certificate using the keytool utility to see
what the difference is. Upon running the openssl x509 -in cert.crt
-noout -text command on this certificate, the output I get is (only
public key info for brevity):
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
EC Public Key:
pub:
04:99:cc:aa:5b:7d:fc:e1:aa:c8:0e:d0:98:b2:ed:
79:65:cb:66:7e:0f:c2:b9:7b:28:42:1b:65:1a:86:
4b:02:dc:7c:5f:d1:21:1f:ca:f2:ac
* ASN1 OID: secp160k1*
Which is different from the openssl generated certificates in that it
has the curve name in the public key, instead of the curve parameters.
The same data (ASN1 OID: secp160k1) in an openssl certificate is:
Field Type: prime-field
Prime:
00:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
ff:fe:ff:ff:ac:73
A:0
B:7 (0x7)
Generator (uncompressed):
04:3b:4c:38:2c:e3:7a:a1:92:a4:01:9e:76:30:36:
f4:f5:dd:4d:7e:bb:93:8c:f9:35:31:8f:dc:ed:6b:
c2:82:86:53:17:33:c3:f0:3c:4f:ee
Order:
01:00:00:00:00:00:00:00:00:00:01:b8:fa:16:df:
ab:9a:ca:16:b6:b3
Cofactor: 1 (0x1)
The keytool output does not seem to be incorrect according to RFC 5280,
which defines
SubjectPublicKeyInfo ::= SEQUENCE {
algoritmAlgorithmIdentifier
subjectPublicKey BIT STRING
}
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL }
unless I am reading this wrong, but the way algorithm parameters are
defined seem to allow for both variants.
I'm looking into making the java certificate store understand
openssl-generated certificates (possibly with 3rd party APIs) as that
would make my life easier.
However, at the same time I'm trying to tackle the problem at the other
end, so I was also wondering if I can get (maybe programatically ?),
openssl to output the public key info in the way in which the keytool
understands: the curve name instead of the curve parameters.
I've had no trouble using a client written in C with openssl to connect
to the above mentioned server (using the keytool generated certificate
as the server certificate), but since I need some certificate request
interaction between the java and C sides, I need to look into this issue
further.
Any ideas on how to get the curve name in the certificate instead of the
curve parameters ?
Thanks in advance,
--
Laura
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
ecdsa-signed certificates algorithm recognition problems
:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff: ff:ff:7f:ff:ff:fc B: 1c:97:be:fc:54:bd:7a:8b:65:ac:f8:9f:81:d4:d4: ad:c5:65:fa:45 Generator (uncompressed): 04:4a:96:b5:68:8e:f5:73:28:46:64:69:89:68:c3: 8b:b9:13:cb:fc:82:23:a6:28:55:31:68:94:7d:59: dc:c9:12:04:23:51:37:7a:c5:fb:32 Order: 01:00:00:00:00:00:00:00:00:00:01:f4:c8:f9:27: ae:d3:ca:75:22:57 Cofactor: 1 (0x1) Seed: 10:53:cd:e4:2c:14:d6:96:e6:76:87:56:15:17:53: 3b:f3:f8:33:45 Signature Algorithm: ecdsa-with-SHA1 30:2e:02:15:00:9f:4d:cc:30:d1:0b:8e:ff:3b:39:07:3f:5d: 13:7c:4f:db:ba:8a:da:02:15:00:d9:89:e4:24:15:f2:ca:9e: f8:39:d3:14:f4:4e:eb:20:d2:cd:1e:87 Thanks in advance, Laura __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: ecdsa-signed certificates algorithm recognition problems
Just a quick note. openss x509 prints out the correct thing if I use 0.9.8h (the default openssl on my machine is 0.9.7-something). Now just the java part of my problem remains, but I suspect that has something to do with my setup. Sorry for the previous message. Laura Laura Arhire wrote: Hello I have successfully managed to create and use certificates which contained and were signed by ecdsa keys in my own prototype program. However, upon attempting to import such a certificate in the java certificate store, I came upon some trouble. It seems there is something wrong with the way I am generating these certificates, as the signature algorithm and the public key algorithm come up as unknown. Sorry for lengthy message which follows. In short, I have the following certificate in PEM format: -BEGIN CERTIFICATE- MIIB+DCCAbagAwIBAgIBAzAJBgcqhkjOPQQBMEkxCzAJBgNVBAYTAlJPMR8wHQYD VQQDExZJbmNvcnJlY3QgVGVzdGluZyBUZWFtMRkwFwYDVQQKExBpbmNvcnJlY3Qt Y2xpZW50MB4XDTA5MDgxNzA5MTkxM1oXDTEwMDgxNzA5MTkxM1owSTELMAkGA1UE BhMCUk8xHzAdBgNVBAMTFkluY29ycmVjdCBUZXN0aW5nIFRlYW0xGTAXBgNVBAoT EGluY29ycmVjdC1jbGllbnQwgeowgbsGByqGSM49AgEwga8CAQEwIAYHKoZIzj0B AQIVAP9/MEMEFP98 BBQcl778VL16i2Ws+J+B1NStxWX6RQMVABBTzeQsFNaW5naHVhUXUzvz+DNFBCkE Spa1aI71cyhGZGmJaMOLuRPL/IIjpihVMWiUfVncyRIEI1E3esX7MgIVAQAA AAH0yPknrtPKdSJXAgEBAyoABAm8/G3NfWWhjeRofpq+hNTibLFO/qRFRPoK yjjVrr53ZII/d++boA8wCQYHKoZIzj0EAQMxADAuAhUAn03MMNELjv87OQc/XRN8 T9u6itoCFQDZieQkFfLKnvg50xT0Tusg0s0ehw== -END CERTIFICATE- (prettyfied version to be found at bottom). When running openssl x509 -in wrong-root-ecdsa160.crt -noout -text on it, I get: Certificate: Data: Version: 3 (0x2) Serial Number: 3 (0x3) Signature Algorithm: UNKNOWN Issuer: C=RO, CN=Incorrect Testing Team, O=incorrect-client Validity Not Before: Aug 17 09:19:13 2009 GMT Not After : Aug 17 09:19:13 2010 GMT Subject: C=RO, CN=Incorrect Testing Team, O=incorrect-client Subject Public Key Info: Public Key Algorithm: UNKNOWN Unable to load Public Key 3104:error:0D09C08F:asn1 encoding routines:d2i_PublicKey:unknown public key type:d2i_pu.c:104: 3104:error:0B077066:x509 certificate routines:X509_PUBKEY_get:err asn1 lib:x_pubkey.c:228: Signature Algorithm: UNKNOWN 30:2e:02:15:00:9f:4d:cc:30:d1:0b:8e:ff:3b:39:07:3f:5d: 13:7c:4f:db:ba:8a:da:02:15:00:d9:89:e4:24:15:f2:ca:9e: f8:39:d3:14:f4:4e:eb:20:d2:cd:1e:87 I suspect the reason why the signature/public key algorithms come up as unknown is the same reason I can't get java to load up this certificate as well. The code used to generate this certificate is (removed return-value testing for brevity): EC_KEY *ec_key = EC_KEY_new_by_curve_name(NID_secp160r1); EC_KEY_generate_key(ec_key); EC_KEY_check_key(ec_key); FILE *f; X509 *x; EVP_PKEY *pk; X509_NAME *name = NULL; pk=EVP_PKEY_new(); x=X509_new(); EVP_PKEY_assign_EC_KEY(pk, ec_key); f = fopen(wrong-root-ecdsa160.key, w); PEM_write_PrivateKey(f, pk, NULL, NULL, 0, 0, NULL); fclose(f); X509_set_version(x, 2); ASN1_INTEGER_set(X509_get_serialNumber(x), 3); // certificate validity X509_gmtime_adj(X509_get_notBefore(x), 0); X509_gmtime_adj(X509_get_notAfter(x), (long) 60 * 60 * 24 * 365); X509_set_pubkey(x, pk); name = X509_get_subject_name(x); const char *grp = incorrect-client; X509_NAME_add_entry_by_txt(name, C, MBSTRING_ASC, (const unsigned char*) RO, -1, -1, 0); X509_NAME_add_entry_by_txt(name, CN, MBSTRING_ASC, (const unsigned char*) Incorrect Testing Team, -1, -1, 0); X509_NAME_add_entry_by_txt(name, O, MBSTRING_ASC, (const unsigned char*) grp, -1, -1, 0); X509_set_issuer_name(x, name); X509_sign(x, pk, EVP_ecdsa()); f = fopen(wrong-root-ecdsa160.crt, w); PEM_write_X509(f, x); fclose(f); I can use such the certificate without a problem in my prototype, add it to the trusted CAs, use it in client-server handshake etc. Any ideas on what I'm doing wrong and how can i get the openssl x509 command to output the correct certificate? If I run: FILE *root_file = fopen(wrong-root-ecdsa160.crt, r); X509 *root_cert = PEM_read_X509(root_file, NULL, NULL, NULL); X509_print_fp(stdout, root_cert); everything prints out as expected: Certificate: Data: Version: 3 (0x2) Serial Number: 3 (0x3) Signature Algorithm: ecdsa-with-SHA1 Issuer: C=RO, CN=Incorrect Testing Team, O=incorrect-client Validity Not Before: Aug 17 09:19:13 2009 GMT Not After : Aug 17 09:19:13 2010 GMT Subject: C=RO, CN=Incorrect Testing Team, O=incorrect-client Subject Public Key Info: Public Key Algorithm: id-ecPublicKey EC Public Key: pub: 04:09:bc:fc:6d:cd:7d:65:a1:8d:e4:68:7e:9a:be: 84:d4:e2
Retrieving hostname after accept
Hello
I have a simple question that I can't find an answer to. I'm writing an
application where every instance is both client and server (a thread is
listening for incoming connections on a predefined port, and at the same
time connections are created to others whenever they're needed).
Whenever I accept an incoming connection, I'd like to be able to retain
the IP address which has just connected (for future use and logging).
I thought I'd be able to achieve this by using the following code
(truncated to essentials, left out error handling):
if (BIO_do_accept(accept_bio) 0)
{
client = BIO_pop(accept_bio);
BIO_get_conn_hostname(client); // returns NULL
}
However, I've found that BIO_get_conn_hostname() always returns NULL on
incoming connections. This happens for all connections (plain/SSL). The
connections, however, work fine and transmit data as they should. I
assume this is intended - that the hostname is null, but I don't know
how to go about actually retrieving it. I'd like to keep using the BIO
abstraction if possible. How would I go on from here?
Thanks in advance,
Laura
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Re: Spam: POLICY_MAPPING_free?
Thanks! but i can't use them. The error isundefined reference to `POLICY_CONSTRAINTS_free'. i can't find any files including these macros. === 2006-12-21 14:47:00 === On Thu, Dec 21, 2006, laura wrote: hi where can i find the definition of these functions: POLICY_MAPPING_free,NAME_CONSTRAINTS_free,POLICY_CONSTRAINTS_free etc? i can't find them in openssl0.9.8b. They are defined through the ASN1 macros. All they do is to free up the corresponding struture. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] . = = = = = = = = = = = = = = = = = = = = 致 礼！ laura [EMAIL PROTECTED] 2006-12-22 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
subjectinfoaccess?
hi, I want to use SIA(subjectinfoaccess) to get the url of caRepository. but i can't find the accessmethod. it should be nid_ad_caRepository defined in rfc3280. does openssl support it? laura [EMAIL PROTECTED] 2006-09-20 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
