Hi all,
I was wondering if there is a list of all CipherSuite[s] and
CompressionMethod[s] supported by OpenSSL. At this point,
I would prefer not to go through the code to get an answer, but
if you guys would point me at a file name, I would gladly take
that, as well :)
Richard
On Wed, Jun 25, 2008 at 16:26, Bill Colvin [EMAIL PROTECTED] wrote:
http://openssl.hoxt.com/openssl-web/docs/apps/ciphers.html
Thanks! From the man page of ciphers, I assume I need to bake my
own OpenSSL binaries to enable NULL ciphers?
And yes, I know what I am doing and yes, in this stage,
My certificate uses a SHA256 hash and the client has OpenSSL 0.9.7.
0.9.8 is needed to support SHA256 hashes.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List
Hi all,
I have my own CA tree, with the relevant part being:
root CA {1}
\- VPN CA {2}
\- server CA {3}
|- server certificate {4}
\- client certificate {5}
I put 1 2 into /etc/ssl/certs/ of the server and 3 into
/etc/openvpn/default/default-ca.pem . The server does, of
Hi all,
basically, I am wondering if there is a real difference between signing
a normal CSR and signing a plain public key while defining the
appropriate X509 v3 extensions at sign time. I suspect that there is no
difference that would matter from the end user's perspective, but I am
far from
On 20/09/2007, Rodney Thayer [EMAIL PROTECTED] wrote:
That being said the existence of any code that handles that
sort of thing is interesting, since there are so few implementations.
Yes, it seems that everyone who does any real work in this direction
keeps the fruits to themselves :/
If I
I am replying to myself to clarify somthing which I should have put
better:
I want to run my own CA, not buy certificates from established ones.
Sorry for asking a misleading question :/
Richard
__
OpenSSL Project
Hi all,
I am looking for existing implementation of a CA that supports external
APIs. Ideally, it should be able to speak XMLRPC or, at least, offer
an API.
Thanks,
Richard
__
OpenSSL Project
On 13/09/2007, Rodney Thayer [EMAIL PROTECTED] wrote:
Why XMLRPC instead of any of the existing online enrollment protocols?
Well, the main reason is that, like it or not, XMLRPC is developing into
a kind of lingua franca when it comes to interoperability. The easy
availablity of TLS for this
