Re: Best Practices CA manage
On Tuesday 13. August 2013 06:17:35 redpath wrote: I have a best practices question on CA management for signing. I have created CA signing cert and issue all other certs using this CA to sign them. 1) I noticed that many CA examples set a term of 3650 days, is this commmon practice How long you issue your CA certificate depends mainly on the strength of the key and the digest algorithm used to sign it. Yes, 10 years is common, but not exactly a rule 2) If I decide to revoke the CA and create a new CA what is the practice for all the certs on this CA do I revoke them and reissue new when needed. If you revoke a CA certificate, all certificates issued by it become invalid automatically as well. So you need to reissue them using your new CA. 3) Currenlty the public CRL is signed by the CA what do I do about this for the new CA. Unless you state a different certificate within the certificate certificate, a CRL has to be signed by the CA itself. 4) For OCSP how does this work out for the new CA, I think the OCSP can take more than one CA to know about, but what abut the OCSP signing cert do I create a a new one there with the new CA? Same as with CRL. 5) I have an SSL cert on the current CA do I create a new one with the new CA and simply replace the the old one. I don't really understand your question here. What is the difference between create a new certificate and replace the old certificate? cheers Mat __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: RAND_bytes() returns zero in pre-boot environment
Issue is fixed.
So long as it's OK to generate the same random bytes at each power-on.
This is quite a common problem with embedded devices: even after boot it
can be hard to find entropy with which to seed the PRNG. The usual
sources which are used in a PC environment (keystrokes, ethernet activity,
...) are often absent.
The best solution is always hardware. If you wire up a digital i/o in such
a way that reading it produces an unpredictable series of 0's and 1's[1]
then at least you have some genuine entropy to work with. It doesn't have
to be ERNIE[2] to be better than nothing.
[1] Exactly how to do this is off-topic for this list. Quaerendo invenietis.
[2] For non-Brits: http://en.wikipedia.org/wiki/Premium_Bond#ERNIE.
FYI-
As I am working on pre-boot, no OS is present. Which was resulting in no
seeding.
RAND_seed() has been called before using RAND_bytes().
Here is the code snippet.
static const char rnd_seed[] = string to make the random number generator
think it has entropy;
RAND_seed(rnd_seed, sizeof rnd_seed);
On Tue, Aug 13, 2013 at 6:16 PM, baban devkate baban...@gmail.com wrote:
FYI -
RAND_bytes(buf, bytes) receives correct parameters as bytes=256 for
SHA256.
int RAND_bytes(unsigned char *buf, int num)
{
const RAND_METHOD *meth = RAND_get_rand_method();
if (meth meth-bytes)
{
Print(L control is here\n);/---controll is here
return meth-bytes(buf,num);
}
Print(L RAND_bytes fails\n);
return(-1);
}
On Tue, Aug 13, 2013 at 3:35 PM, baban devkate baban...@gmail.com
wrote:
Hello,
RAND_bytes() will use the proper OS-provided RNG e.g. /dev/urandom or
/dev/randomon Linux and CryptGenRandom() on Windows.
I want to know how it works in Pre-boot environement?
In pre-boot environment, if RAND_bytes() returns zero then what does it
mean?
Is it because PRNG is not properly seeded? If yes, how to resolve it?
~Baban
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Best Practices CA manage
Thanks and as for the last question number (5) I meant I simply replace the SSL cert and assume there will be a challenge to accept the new certificate by a browser? I revoke the old one SSL cert. -- View this message in context: http://openssl.6102.n7.nabble.com/Best-Practices-CA-manage-tp46134p46142.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: Best Practices CA manage
On Wednesday 14. August 2013 04:10:23 you wrote: Thanks and as for the last question number (5) I meant I simply replace the SSL cert and assume there will be a challenge to accept the new certificate by a browser? I revoke the old one SSL cert. I still don't get it. If you have revoked your old root certificate you have to 1. Create a new SSL certificate 2. Install it into the webserver (assuming you are talking about one), replacing the old one (which has becom invalid) If a browser should automatically accept your new SSL certificate, you have to install your new Root certificate as a trusted one, first. cheers Mat __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Best Practices CA manage
On 08/14/13 09:08, Mat Arge wrote: On Wednesday 14. August 2013 04:10:23 you wrote: Thanks and as for the last question number (5) I meant I simply replace the SSL cert and assume there will be a challenge to accept the new certificate by a browser? I revoke the old one SSL cert. I still don't get it. If you have revoked your old root certificate you have to 1. Create a new SSL certificate 2. Install it into the webserver (assuming you are talking about one), replacing the old one (which has becom invalid) If a browser should automatically accept your new SSL certificate, you have to install your new Root certificate as a trusted one, first. cheers Mat __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org If your web server has a new certificate, and the web browser does not have the new CA root certificate, then the web browser will prompt you about accepting the new certificated. BUT I have found that IE9 and IE10 are a lot pickier about valid certs than IE8 was.You may find that they will not be happy if they cannot verify the certificate chain. So it is probably safer to plan to redistribute the new CA root certificate. Openssl has an option to renew certificates.I don't know if this applies to CA certs. Also, even if you generate a new CA cert it should still have the same public key as the previous CA cert (assuming the same CA private key is used.) So if, for example, your CA cert expires Dec 31, 2013 but the web server cert expired Dec 2013, 2014- you probably wouldn't have to regenerate a new web server cert at the same time as the CA cert. But you still need to push the new CA cert out with the updated expiration date. So you probably DON'T want to revoke the old one , but instead of have an overlap period between the old a new certificate. This assumes your CA private key has been kept secure. (Some people recommend keeping your root CA offline once intermediate CA's have been set up.) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Displaying cert with ecdsa
I have a CA cert in pem format that uses ecdsa. I have tried to display the contents with: openssl x509 -in x509-ca.pem -text -nameopt multiline -noout I get errors: Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Unable to load Public Key 140661212006240:error:0609E09C:digital envelope routines:PKEY_SET_TYPE:unsupported algorithm:p_lib.c:239: 140661212006240:error:0B07706F:x509 certificate routines:X509_PUBKEY_get:unsupported algorithm:x_pubkey.c:155: Is there an option I need to add? Is there something special with this cert's Public Key Algorithm? Thank you. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Displaying cert with ecdsa
From: owner-openssl-us...@openssl.org On Behalf Of Robert Moskowitz Sent: Wednesday, 14 August, 2013 15:49 I have a CA cert in pem format that uses ecdsa. I have tried to display the contents with: openssl x509 -in x509-ca.pem -text -nameopt multiline -noout I get errors: Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Unable to load Public Key 140661212006240:error:0609E09C:digital envelope routines:PKEY_SET_TYPE:unsupported algorithm:p_lib.c:239: 140661212006240:error:0B07706F:x509 certificate routines:X509_PUBKEY_get:unsupported algorithm:x_pubkey.c:155: Is there an option I need to add? Is there something special with this cert's Public Key Algorithm? I'm pretty sure not. OpenSSL versions before 1.0.0 needed a cipherstring option to use ECC suites *in SSL/TLS protocol*, but local operations have worked as long as I remember. What version of OpenSSL are you running, and how was it built? In particular was it from official source, or patched? A couple of remote possibilities: do you have your openssl.cnf set (editted) to load an engine, which doesn't support ECC? I didn't think this level of parsing goes to an engine, but I could be wrong. Do you have a FIPS-capable build and a setting to force FIPS mode? FIPS should allow ECC (it is NIST Approved), but something might be broken. Can you try the same file with a different OpenSSL version or build -- often easiest by using a different system? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Is RFC3268 extension supported in openssl?
From the documents of http://www.openssl.org/docs/apps/ciphers.html and CHANGES with the source code, RFC3268 is stated to be supported. But I cannot get the following ciphers by using openssl ciphers. (I have used openssl1.0.1e and openssl0.9.8y) TLS_DH_DSS_WITH_AES_128_CBC_SHA DH-DSS-AES128-SHA TLS_DH_DSS_WITH_AES_256_CBC_SHA DH-DSS-AES256-SHA TLS_DH_RSA_WITH_AES_128_CBC_SHA DH-RSA-AES128-SHA TLS_DH_RSA_WITH_AES_256_CBC_SHA DH-RSA-AES256-SHA Are they really supported or do I have to enable them when building openssl? -Zyan
