Re: RSA public/private keys only work when created programatically.
Hi,
Your command line that create the public key is missing the -pubout
switch that tells the rsa utility to output a public key. So, this
command should look like : openssl rsa -in rsaprivatekey.pem -out
rsapublickey.pem -pubout . Without it, it will just output the private
key as is.
Moreover, the openssl rsa utility saves the public key using the
function PEM_write_bio_RSA_PUBKEY and not PEM_write_bio_RSAPubicKey. So,
if you want your program to be compatible with its output, then you
should use PEM_write_bio_RSA_PUBKEY and PEM_read_bio_RSA_PUBKEY for
saving/loading public key files.
I hope this will help,
--
Mounir IDRASSI
IDRIX
http://www.idrix.fr
On 2/18/2011 4:59 AM, David Henry wrote:
I've written a bare bones enveloping example that takes a string,
seals it in an envelope, and then goes about opening it. Everything
works just fine if I generate my RSA keys programatically.
Unfortunately, it does not work if I encrypt the session keys with an
RSA public key that was created on the command line like:
> openssl genrsa -out rsaprivatekey.pem
> openssl rsa -in rsaprivatekey.pem -out rsapublickey.pem
I would greatly appreciate if someone could explain why my
programatically-created keys work, but the command-line ones do not.
The code that generates usable keys looks like this:
int main() {
// generate & check keys
RSA* rsa = RSA_generate_key(2048, RSA_F4, NULL, 0);
int check_key = RSA_check_key(rsa);
while (check_key <= 0) {
cerr << "error generating keys -- regenerating...";
rsa = RSA_generate_key(2048, RSA_F4, NULL, 0);
check_key = RSA_check_key(rsa);
}
RSA_blinding_on(rsa, NULL);
// write out pem-encoded public key
BIO* rsaPublicBio = BIO_new_file("rsapublickey.pem", "w");
PEM_write_bio_RSAPublicKey(rsaPublicBio, rsa);
// write out pem-encoded encrypted private key
BIO* rsaPrivateBio = BIO_new_file("rsaprivatekey.pem", "w");
PEM_write_bio_RSAPrivateKey(rsaPrivateBio, rsa, NULL, NULL, 0,
NULL, NULL);
BIO_free(rsaPublicBio);
BIO_free(rsaPrivateBio);
RSA_free(rsa);
...
return 0;
}
The program that uses the keys is:
#include
#include
#include
#include
#include
#define BUF_SIZE4096
#define BLOCK_SIZE32
int main() {
// uninitialized symmetric cipher context
EVP_CIPHER_CTX* ctx = new EVP_CIPHER_CTX;
// symmetric cipher
const EVP_CIPHER* type = EVP_aes_256_cbc();
unsigned char
message[BUF_SIZE] =
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
printf("Unencoded string = {%s}\n", message);
int npubk = 1;
unsigned char** ek = new unsigned char*[npubk];
int* ekl = new int[npubk];
EVP_PKEY** pubk = new EVP_PKEY*[npubk];
// read in pem-encoded public key
BIO* rsa_pub_bio = BIO_new_file("rsapublickey.pem", "r");
RSA* rsa_pub = RSA_new();
PEM_read_bio_RSAPublicKey(rsa_pub_bio, &rsa_pub, NULL, NULL);
BIO_free(rsa_pub_bio);
// encrypt symmetric session keys
for (int i = 0; i < npubk; i++) {
pubk[i] = EVP_PKEY_new();
EVP_PKEY_assign_RSA(pubk[i], rsa_pub);
ek[i] = new unsigned char[EVP_PKEY_size(pubk[i])];
ekl[i] = EVP_PKEY_size(pubk[i]);
}
// random initialization vector
unsigned char* iv = new unsigned char[EVP_MAX_IV_LENGTH];
RAND_pseudo_bytes(iv, EVP_MAX_IV_LENGTH);
int message_len;// initialized by EVP_SealUpdate & EVP_SealFinal
unsigned char encrypt_buf[BUF_SIZE + BLOCK_SIZE];
EVP_SealInit(ctx, type, ek, &ekl[0], &iv[0], &pubk[0], npubk);
// EVP_SealUpdate changes message_len to # bytes in message
EVP_SealUpdate(ctx, encrypt_buf, &message_len, message,
strlen((const char*) message));
printf("buf_len: %d\n", message_len);
int total_len = message_len;// line must be between SealUpdate
& SealFinal
// EVP_SealFinal changes message_len value to # bytes of
encryption overhead
EVP_SealFinal(ctx, &encrypt_buf[message_len], &message_len);
int i;
printf("Encoded string = {");
for (i = 0; i < message_len; i++) {
printf("%02x", encrypt_buf[i]);
}
for (i = 0; i < message_len; i++) {
printf("%02x", encrypt_buf[i + total_len]);
}
printf("}\n");
unsigned char decrypt_buf[BUF_SIZE];
int decrypt_len;// initialized by EVP_OpenUpdate & EVP_OpenFinal
// read in pem-encoded encrypted private key
BIO* rsa_priv_bio = BIO_new_file("rsaprivatekey.pem", "r");
RSA* rsa_priv = RSA_new();
PEM_read_bio_RSAPrivateKey(rsa_priv_bio, &rsa_priv, NULL, NULL);
BIO_free(rsa_priv_bio);
EVP_PKEY* privk = EVP_PKEY_new();
EVP_PKEY_assign_RSA(privk, rsa_priv);
EVP_OpenInit(ctx, type, *ek, ekl[0], &iv[0], privk);
// EVP_Open
RSA public/private keys only work when created programatically.
I've written a bare bones enveloping example that takes a string, seals it
in an envelope, and then goes about opening it. Everything works just fine
if I generate my RSA keys programatically. Unfortunately, it does not work
if I encrypt the session keys with an RSA public key that was created on the
command line like:
> openssl genrsa -out rsaprivatekey.pem
> openssl rsa -in rsaprivatekey.pem -out rsapublickey.pem
I would greatly appreciate if someone could explain why my
programatically-created keys work, but the command-line ones do not. The
code that generates usable keys looks like this:
int main() {
// generate & check keys
RSA* rsa = RSA_generate_key(2048, RSA_F4, NULL, 0);
int check_key = RSA_check_key(rsa);
while (check_key <= 0) {
cerr << "error generating keys -- regenerating...";
rsa = RSA_generate_key(2048, RSA_F4, NULL, 0);
check_key = RSA_check_key(rsa);
}
RSA_blinding_on(rsa, NULL);
// write out pem-encoded public key
BIO* rsaPublicBio = BIO_new_file("rsapublickey.pem", "w");
PEM_write_bio_RSAPublicKey(rsaPublicBio, rsa);
// write out pem-encoded encrypted private key
BIO* rsaPrivateBio = BIO_new_file("rsaprivatekey.pem", "w");
PEM_write_bio_RSAPrivateKey(rsaPrivateBio, rsa, NULL, NULL, 0, NULL,
NULL);
BIO_free(rsaPublicBio);
BIO_free(rsaPrivateBio);
RSA_free(rsa);
...
return 0;
}
The program that uses the keys is:
#include
#include
#include
#include
#include
#define BUF_SIZE4096
#define BLOCK_SIZE32
int main() {
// uninitialized symmetric cipher context
EVP_CIPHER_CTX* ctx = new EVP_CIPHER_CTX;
// symmetric cipher
const EVP_CIPHER* type = EVP_aes_256_cbc();
unsigned char
message[BUF_SIZE] =
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
printf("Unencoded string = {%s}\n", message);
int npubk = 1;
unsigned char** ek = new unsigned char*[npubk];
int* ekl = new int[npubk];
EVP_PKEY** pubk = new EVP_PKEY*[npubk];
// read in pem-encoded public key
BIO* rsa_pub_bio = BIO_new_file("rsapublickey.pem", "r");
RSA* rsa_pub = RSA_new();
PEM_read_bio_RSAPublicKey(rsa_pub_bio, &rsa_pub, NULL, NULL);
BIO_free(rsa_pub_bio);
// encrypt symmetric session keys
for (int i = 0; i < npubk; i++) {
pubk[i] = EVP_PKEY_new();
EVP_PKEY_assign_RSA(pubk[i], rsa_pub);
ek[i] = new unsigned char[EVP_PKEY_size(pubk[i])];
ekl[i] = EVP_PKEY_size(pubk[i]);
}
// random initialization vector
unsigned char* iv = new unsigned char[EVP_MAX_IV_LENGTH];
RAND_pseudo_bytes(iv, EVP_MAX_IV_LENGTH);
int message_len;// initialized by EVP_SealUpdate & EVP_SealFinal
unsigned char encrypt_buf[BUF_SIZE + BLOCK_SIZE];
EVP_SealInit(ctx, type, ek, &ekl[0], &iv[0], &pubk[0], npubk);
// EVP_SealUpdate changes message_len to # bytes in message
EVP_SealUpdate(ctx, encrypt_buf, &message_len, message, strlen((const
char*) message));
printf("buf_len: %d\n", message_len);
int total_len = message_len;// line must be between SealUpdate &
SealFinal
// EVP_SealFinal changes message_len value to # bytes of encryption
overhead
EVP_SealFinal(ctx, &encrypt_buf[message_len], &message_len);
int i;
printf("Encoded string = {");
for (i = 0; i < message_len; i++) {
printf("%02x", encrypt_buf[i]);
}
for (i = 0; i < message_len; i++) {
printf("%02x", encrypt_buf[i + total_len]);
}
printf("}\n");
unsigned char decrypt_buf[BUF_SIZE];
int decrypt_len;// initialized by EVP_OpenUpdate & EVP_OpenFinal
// read in pem-encoded encrypted private key
BIO* rsa_priv_bio = BIO_new_file("rsaprivatekey.pem", "r");
RSA* rsa_priv = RSA_new();
PEM_read_bio_RSAPrivateKey(rsa_priv_bio, &rsa_priv, NULL, NULL);
BIO_free(rsa_priv_bio);
EVP_PKEY* privk = EVP_PKEY_new();
EVP_PKEY_assign_RSA(privk, rsa_priv);
EVP_OpenInit(ctx, type, *ek, ekl[0], &iv[0], privk);
// EVP_OpenUpdate changes decrypt_len to # bytes in decrypted message
EVP_OpenUpdate(ctx, decrypt_buf, &decrypt_len, encrypt_buf, total_len +
message_len);
total_len = decrypt_len;// line must be between OpenUpdate &
OpenFinal
EVP_OpenFinal(ctx, &decrypt_buf[total_len], &decrypt_len);
// EVP_OpenFinal changes decrypt_len value to # bytes of encryption
overhead
decrypt_buf[total_len + decrypt_len] = '\0';
printf("Unencoded string = {%s}\n", decrypt_buf);
delete ctx;
EVP_PKEY_free(privk);
for (int i = 0; i < npubk; i++) {
EVP_PKEY_free(pubk[i]);
delete ek[i];
}
delete[] ek;
delete[] ekl;
delete[] pubk;
delete[] iv;
return 0;
}
Re: ssh FIPS dsa key authentication issue
On Thu, Feb 17, 2011, Hai-May Chao wrote: > Using the EVP_Signxxx API to perform a FIPS mode DSA key sign will > generate a signature with ASN.1 format (fips_dsa_sign.c). Therefore, > the signature size is no longer 40 bytes (rlen = 20 plus slen = 20) > but 48 bytes with padding and ASN.1 overhead (rlen = 20, rpad = 1, > slen = 20, spad = 1, SEQUENCE = 4, SEQUENCE header = 2). > There are two potential issues for this: > > 1) SSH always assume the DSA signature is 40 bytes. This will cause > the sigblob[SIGBLOB_LEN] (in ssh-dss.c) to be overflowed by a DSA > signature in ASN.1 format, and thus smashes the SSH's stack. > > 2) When a SSH client in FIPS mode communicates with a non-FIPS SSHD > using the DSA key authentication. the authentication will fail. This is > because SSH will generate a 48 bytes signature (in ASN.1 format) > by calling the EVP_SignFinal() API, while the SSHD will still > assume a 40-byte raw signature when performing the verification. > > Is there a way to resolve these issues (specially on issue #2)? > You can convert between the two formats readily enough. If you call d2i_DSA_SIG() on the output of EVP_Sign*() you'll get a DSA_SIG structure. You can then convert (padding if necessary) the two r and s BIGNUMs of the signature. You do the revrse to convert the 40 byte format to ASN.1. 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
ssh FIPS dsa key authentication issue
Using the EVP_Signxxx API to perform a FIPS mode DSA key sign will generate a signature with ASN.1 format (fips_dsa_sign.c). Therefore, the signature size is no longer 40 bytes (rlen = 20 plus slen = 20) but 48 bytes with padding and ASN.1 overhead (rlen = 20, rpad = 1, slen = 20, spad = 1, SEQUENCE = 4, SEQUENCE header = 2). There are two potential issues for this: 1) SSH always assume the DSA signature is 40 bytes. This will cause the sigblob[SIGBLOB_LEN] (in ssh-dss.c) to be overflowed by a DSA signature in ASN.1 format, and thus smashes the SSH's stack. 2) When a SSH client in FIPS mode communicates with a non-FIPS SSHD using the DSA key authentication. the authentication will fail. This is because SSH will generate a 48 bytes signature (in ASN.1 format) by calling the EVP_SignFinal() API, while the SSHD will still assume a 40-byte raw signature when performing the verification. Is there a way to resolve these issues (specially on issue #2)? Thank you very much. Hai-May __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
PRNG not seeded error when running make tests on TRU64 (AKA DEC Unix) -- Yes, I did read the FAQ.
First off, yes, I did read the FAQ. I am trying to build 9.8.0r on an old Dec Unix (aka tru64 Alpha) machine, specifically OSF1 V4.0. I'm getting the PRNG not seeded error when running the tests. Yes, I did read the FAQ. Now this machine is pretty old, and AFAIK, has no random device. I did try and improvise one by using the RANDFILE environment variable pointing to a file with random data. That didn't fix the problem either. The FAQ really doesn't say much about what needs to be in the file, perhaps I didn't have enough random data? Is this test, 'testca' one of the alluded to areas of the code that does not use RANDFILE? Anyone else have any ideas? Generating a 1024 bit RSA private key ++ ++ writing new private key to 'newkey.pem' - You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. - Country Name (2 letter code) [AU]:AU Organization Name (eg, company) []:Dodgy Brothers Common Name (eg, YOUR name) []:Brother 1 Common Name (eg, YOUR name) []:Brother 2 Request is in newreq.pem, private key is in newkey.pem Using configuration from ../apps/openssl.cnf unable to load 'random state' This means that the random number generator has not been seeded with much random data. Check that the request matches the signature Signature ok Certificate Details: Serial Number: 9f:56:84:ab:1d:33:70:0d Validity Not Before: Feb 17 17:53:19 2011 GMT Not After : Feb 17 17:53:19 2012 GMT Subject: countryName = AU organizationName = Dodgy Brothers commonName= Brother 1 commonName= Brother 2 X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 35:3F:A9:F0:64:CF:7A:A2:A9:80:56:84:44:90:55:8F:EF:73:93:F3 X509v3 Authority Key Identifier: keyid:89:61:52:C8:2D:80:03:5F:7C:83:2C:98:6C:1D:39:9E:DC:BA:FE:A8 Certificate is to be certified until Feb 17 17:53:19 2012 GMT (365 days) Sign the certificate? [y/n]:13527:error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not seeded:md_rand.c:515:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html 13527:error:04088003:rsa routines:RSA_setup_blinding:BN lib:rsa_lib.c:222: 13527:error:04066044:rsa routines:RSA_EAY_PRIVATE_ENCRYPT:internal error:rsa_eay.c:401: 13527:error:0D0C3006:asn1 encoding routines:ASN1_item_sign:EVP lib:a_sign.c:281: Signed certificate is in newcert.pem *** Exit 1 Stop. *** Exit 1 Stop.
AW: Adding non-root certificates to the list of trusted certificates?
> -Original Message- > From: Eisenacher, Patrick > > > Matthias, search the archives for a thread named 'Terminate chain at > intermediate certificate'. Stephan's post that Mounir cites, is from last > year's 11th November. > Thanks for this information, I will see how far I get. - Matthias Meixner __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
cmake and openssl
Hello, I am novice in build system. I use cmake. I have to indicate to cmake where it can find openssl library. 1) which library have I to include ? In /lib/ directory, there is /lib/libssl.so.0.9.8 , in /lib/usr/ directory there are : /usr/lib/libssl.so /usr/lib/libssl.so.0.9.8 /usr/lib/libssl.a /usr/lib/libssl3.so /usr/lib/libssl3.so.1d /usr/lib/pkgconfig/libssl.pc /usr/lib/firefox-3.6.13/libssl3.so 2) what kind of expression have I to add in CMakeLists.txt and CMakeCache.txt ? Thanks for your help.
RE: [FWD] Intermediate certificate chain not included when exporting as pkcs12
> -Original Message- > From: Lutz Jaenicke > > Forwarded to openssl-users for discussion. > > Best regards, > Lutz > - Forwarded message from Alexander Mills - > > From: Alexander Mills > > Recently I was tasked with using a .crt and .key used in Apache for > use with Apache Tomcat. I searched around and the solution was to use > the following command, where the p7b file is the intermediate > certificate provided by Thawte. > > openssl pkcs12 -export -in myCert.crt -inkey myKey.key -out > mypkcs12.p12 -name tomcat -CAfile ssl_pkcs7.p7b -caname root -chain > > For some reason, which I am yet to fathom, the above command will not > export the intermediate chain, and thus the certificate becomes > untrustworthy. The following command works for me: $openssl pkcs12 -export -in cert.pem -inkey key.pem -name mylabel -chain -CAfile ca_path.pem -out archive.p12 -passout pass:mypassphrase ca_path.pem contains the concatenated CA certificates of cert.pem's certificate chain, encoded in PEM-format. So obviously what you pass in via -CAfile has the wrong format. Also make sure that all CA certificates of your chain are included in that file. HTH, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Shared library problem ?- Solaris - nonstandard ssl folder
Hello all. I'm trying to build openssl 1.0.0 (c/d) on Solaris 10 u8 (x86/64bit). I compiled it in 64-bit mode and with key -openssldir=/usr/local/ssl64 Make is ok and make test/install is ok. But, when I'm checking links for shared librares, I see that link to libcrypto isn't found: # ldd libssl.so.1.0.0 libcrypto.so.1.0.0 =>(file not found) libsocket.so.1 =>/lib/64/libsocket.so.1 libnsl.so.1 => /lib/64/libnsl.so.1 libdl.so.1 =>/lib/64/libdl.so.1 libz.so.1 => /usr/lib/64/libz.so.1 libc.so.1 => /lib/64/libc.so.1 libmp.so.2 =>/lib/64/libmp.so.2 libmd.so.1 =>/lib/64/libmd.so.1 libscf.so.1 => /lib/64/libscf.so.1 libdoor.so.1 => /lib/64/libdoor.so.1 libuutil.so.1 => /lib/64/libuutil.so.1 libgen.so.1 => /lib/64/libgen.so.1 libm.so.2 => /lib/64/libm.so.2 Is it normal ?) Adding to LDFLAGS -R/usr/local/ssl64 or -L/usr/local/ssl64 doesn't help. Building script: - CC="cc" CFLAGS="-m64" CXXFLAGS="-m64" LDFLAGS="-R/lib/64 -L/lib/64" export CC export CFLAGS export CXXFLAGS export LDFLAGS make clean ./config --openssldir=/usr/local/ssl64 shared zlib threads >./config.log make - Thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Problem with multiple level CA
Federico, thank for quick answer. I'm still not sure if it is necessary to install ROOT CA on all users computers. I generated user certificate with such commands: openssl req -newkey rsa:1024 -keyout user.key -config openssl.cnf -out user.req openssl ca -config openssl.cnf -out user.crt -infiles user.req And then I tried to generate pfx file with chaon (as i understand in this case user will not need to install ROOT CA because this certificate will be included into user's certificate). But I got an error: C:\temp\CA_NEW2>cs12 -export -chain -in user.crt -inkey user.key -certfile CondorSigningCA/signing-ca.crt -out user.pfx Loading 'screen' into random state - done Enter pass phrase for user.key: Error unable to get local issuer certificate getting chain. Or in any case I need to install ROOT CA certificate and then user certificate on any user's computer? thanks, -- Tanya. On Thu, Feb 17, 2011 at 11:40 AM, Federico Berton wrote: > Yes, regardless of the OS because it needs to know that you approve that your > home-made ROOT CA is credible. > > > FEDERICO BERTON > AREA SVILUPPO > > Via Europa, 20 > 35015 Galliera Veneta (PD) > TEL. 049.9988200 FAX 049.9471337 > http://www.trivenet.it > > > -Messaggio originale- > Da: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] > Per conto di Tanya Lozovaya > Inviato: giovedì 17 febbraio 2011 10:25 > A: openssl-users@openssl.org > Cc: Federico Berton > Oggetto: Re: Problem with multiple level CA > > No, should I? > If I'm going to generate user keys-certificates that will be signed by > SIGNING CA certificate, should I force all users to install ROOT CA as > trusted certificate? > > On Thu, Feb 17, 2011 at 11:08 AM, Federico Berton > wrote: >> Have you added the ROOTCA certificate in the trusted root certificate? >> >> FEDERICO BERTON >> AREA SVILUPPO >> >> Via Europa, 20 >> 35015 Galliera Veneta (PD) >> TEL. 049.9988200 FAX 049.9471337 >> http://www.trivenet.it >> >> >> -Messaggio originale- >> Da: owner-openssl-us...@openssl.org >> [mailto:owner-openssl-us...@openssl.org] Per conto di Tanya Lozovaya >> Inviato: giovedì 17 febbraio 2011 09:49 >> A: d...@deadhat.com; openssl-users@openssl.org >> Oggetto: Re: Problem with multiple level CA >> >> I tried to open crt file on different computers and I got different errors: >> >> on Windows 7: The issuer of this certificate could not be found. >> on Windows 2003: This certificate has an nonvalid digital signature. >> >> Do anybody know how I can make the computers to "think" that self-signed >> "ROOT CA" certificate is valid (trusted) and it is the parent for "SIGNING >> CA"? >> >> Thanks, >> -- >> Tanya. >> >> On Wed, Feb 16, 2011 at 10:19 PM, wrote: >>> Yes, I used your config files. >>> >>> With Windows 2003 (Which is a version of Windows 2000), you don't >>> have >>> RSA2048 support, so it can't verify the signature. >>> >>> However if you verify the signature in openssl, it is fine, since >>> openssl supports RSA2048. >>> >>> E.G.: >>> [root@dj-desk1 ~]# openssl verify -CAfile root-ca.crt signing-ca.crt >>> signing-ca.crt: OK >>> >>> >>> I use Windows 2003. Did you try my config files? Thanks, -- Tanya. On Wed, Feb 16, 2011 at 8:15 PM, wrote: > It worked for me. > > Are you using Windows XP? Except for a recent update, XP didn't > support > 2048 RSA. > > Regards, > David > > >> Hi guys, >> >> I have tried to configure multiple level CA structure: ROOT CA -> >> SIGNING CA -> Users certificates I use RootSSL.cnf file and these >> commands to generate root certificate: >> openssl genrsa -des3 -out root-ca.key 2048 >> openssl req -new -x509 -days 3650 -key root-ca.key -out >> root-ca.crt -config RootSSL.cnf >> >> In order to generate intermediate CA I use OpenSSL.cnf file and >> these >> commands: >> openssl genrsa -des3 -out signing-ca.key 2048 >> openssl req -new -days 1095 -key signing-ca.key -out >> signing-ca.csr -config openssl.cnf >> openssl ca -config openssl.cnf -name CA_root -extensions >> v3_ca -out signing-ca.crt -infiles signing-ca.csr >> >> As the result I have OK root certificate, but I see error message >> for signing certificate: "This certificate has an nonvalid digital >> signature." >> >> Can somebody advise me what I do wrong? >> >> Thanks, >> -- >> Tanya Lozovaya. >> > > -- Tanya Lozovaya. >>> >>> >> >> >> >> -- >> Tanya Lozovaya. >> __ >> OpenSSL Project http://www.openssl.org >> User Support Mailing List openssl-users@openssl.org >> Automated List Manager majord...@openssl.org >> ___
Re: [FWD] Intermediate certificate chain not included when exporting as pkcs12
I had this problem, too. A workaround that does the trick for me is to - encode the key and any certificate you'd like to export to the .p12 as PEM - Paste the PEM key and all the PEM certificates into one single file (let's assume all.pem) - then issue the following command: openssl pkcs12 -export -in all.pem -out mypkcs12.p12 -name tomcat Regards, Martin 2011/2/17 Lutz Jaenicke : > Forwarded to openssl-users for discussion. > > Best regards, > Lutz > - Forwarded message from Alexander Mills > - > > From: Alexander Mills > To: r...@openssl.org > Subject: Intermediate certificate chain not included when exporting as pkcs12 > Date: Thu, 17 Feb 2011 09:15:37 + > > Recently I was tasked with using a .crt and .key used in Apache for > use with Apache Tomcat. I searched around and the solution was to use > the following command, where the p7b file is the intermediate > certificate provided by Thawte. > > openssl pkcs12 -export -in myCert.crt -inkey myKey.key -out > mypkcs12.p12 -name tomcat -CAfile ssl_pkcs7.p7b -caname root -chain > > For some reason, which I am yet to fathom, the above command will not > export the intermediate chain, and thus the certificate becomes > untrustworthy. > The only solution I have been able to find is to use Internet Explorer. > > I've written the instructions for IE below, but I'm perplexed as to > why openssl isn't behaving as I thought it would have (and clearly > others feel this way). > > Open IE > Click Tools > Click Internet Options > Click Content > Click Certificates > Import the p12 file into the Personal Store > Go to the Truster Root Certification Authorities tab > Delete “Thawte Primary Root CA” issued by “Thawte Primary Root CA” > Import the intermediate file from the following link into the > Intermediate Certification tab: > https://search.thawte.com/support/ssl-digital-certificates/index?page=content&actp=CROSSLINK&id=AR1373 > Right click 'Download the PKCS#7 CA' and save the file and import that > file into the Intermediate Certification AUthorities tab > Then go back to the Personal Store tab > Double click the certificate > Click the certification path tab > There should be 4 certificates in the certificate hierarchy at this > stage > Highlight the certificate in the Personal Store > Click on Export > Click 'Yes, export private key' > Click Next > Put a tick in the first checkbox only, not the other two > Finish the wizard > Rename the PFX file you create to have a p12 extension > Use the new .p12 file in Tomcat > > > > - End forwarded message - > -- > Lutz Jaenicke jaeni...@openssl.org > OpenSSL Project http://www.openssl.org/~jaenicke/ > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-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
R: Problem with multiple level CA
Yes, regardless of the OS because it needs to know that you approve that your home-made ROOT CA is credible. FEDERICO BERTON AREA SVILUPPO Via Europa, 20 35015 Galliera Veneta (PD) TEL. 049.9988200 FAX 049.9471337 http://www.trivenet.it -Messaggio originale- Da: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] Per conto di Tanya Lozovaya Inviato: giovedì 17 febbraio 2011 10:25 A: openssl-users@openssl.org Cc: Federico Berton Oggetto: Re: Problem with multiple level CA No, should I? If I'm going to generate user keys-certificates that will be signed by SIGNING CA certificate, should I force all users to install ROOT CA as trusted certificate? On Thu, Feb 17, 2011 at 11:08 AM, Federico Berton wrote: > Have you added the ROOTCA certificate in the trusted root certificate? > > FEDERICO BERTON > AREA SVILUPPO > > Via Europa, 20 > 35015 Galliera Veneta (PD) > TEL. 049.9988200 FAX 049.9471337 > http://www.trivenet.it > > > -Messaggio originale- > Da: owner-openssl-us...@openssl.org > [mailto:owner-openssl-us...@openssl.org] Per conto di Tanya Lozovaya > Inviato: giovedì 17 febbraio 2011 09:49 > A: d...@deadhat.com; openssl-users@openssl.org > Oggetto: Re: Problem with multiple level CA > > I tried to open crt file on different computers and I got different errors: > > on Windows 7: The issuer of this certificate could not be found. > on Windows 2003: This certificate has an nonvalid digital signature. > > Do anybody know how I can make the computers to "think" that self-signed > "ROOT CA" certificate is valid (trusted) and it is the parent for "SIGNING > CA"? > > Thanks, > -- > Tanya. > > On Wed, Feb 16, 2011 at 10:19 PM, wrote: >> Yes, I used your config files. >> >> With Windows 2003 (Which is a version of Windows 2000), you don't >> have >> RSA2048 support, so it can't verify the signature. >> >> However if you verify the signature in openssl, it is fine, since >> openssl supports RSA2048. >> >> E.G.: >> [root@dj-desk1 ~]# openssl verify -CAfile root-ca.crt signing-ca.crt >> signing-ca.crt: OK >> >> >> >>> I use Windows 2003. >>> >>> Did you try my config files? >>> >>> Thanks, >>> -- >>> Tanya. >>> >>> On Wed, Feb 16, 2011 at 8:15 PM, wrote: It worked for me. Are you using Windows XP? Except for a recent update, XP didn't support 2048 RSA. Regards, David > Hi guys, > > I have tried to configure multiple level CA structure: ROOT CA -> > SIGNING CA -> Users certificates I use RootSSL.cnf file and these > commands to generate root certificate: > openssl genrsa -des3 -out root-ca.key 2048 > openssl req -new -x509 -days 3650 -key root-ca.key -out > root-ca.crt -config RootSSL.cnf > > In order to generate intermediate CA I use OpenSSL.cnf file and > these > commands: > openssl genrsa -des3 -out signing-ca.key 2048 > openssl req -new -days 1095 -key signing-ca.key -out > signing-ca.csr -config openssl.cnf > openssl ca -config openssl.cnf -name CA_root -extensions > v3_ca -out signing-ca.crt -infiles signing-ca.csr > > As the result I have OK root certificate, but I see error message > for signing certificate: "This certificate has an nonvalid digital > signature." > > Can somebody advise me what I do wrong? > > Thanks, > -- > Tanya Lozovaya. > >>> >>> >>> >>> -- >>> Tanya Lozovaya. >>> >> >> > > > > -- > Tanya Lozovaya. > __ > 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 > -- Tanya Lozovaya. __ 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
[FWD] Intermediate certificate chain not included when exporting as pkcs12
Forwarded to openssl-users for discussion. Best regards, Lutz - Forwarded message from Alexander Mills - From: Alexander Mills To: r...@openssl.org Subject: Intermediate certificate chain not included when exporting as pkcs12 Date: Thu, 17 Feb 2011 09:15:37 + Recently I was tasked with using a .crt and .key used in Apache for use with Apache Tomcat. I searched around and the solution was to use the following command, where the p7b file is the intermediate certificate provided by Thawte. openssl pkcs12 -export -in myCert.crt -inkey myKey.key -out mypkcs12.p12 -name tomcat -CAfile ssl_pkcs7.p7b -caname root -chain For some reason, which I am yet to fathom, the above command will not export the intermediate chain, and thus the certificate becomes untrustworthy. The only solution I have been able to find is to use Internet Explorer. I've written the instructions for IE below, but I'm perplexed as to why openssl isn't behaving as I thought it would have (and clearly others feel this way). Open IE Click Tools Click Internet Options Click Content Click Certificates Import the p12 file into the Personal Store Go to the Truster Root Certification Authorities tab Delete “Thawte Primary Root CA” issued by “Thawte Primary Root CA” Import the intermediate file from the following link into the Intermediate Certification tab: https://search.thawte.com/support/ssl-digital-certificates/index?page=content&actp=CROSSLINK&id=AR1373 Right click 'Download the PKCS#7 CA' and save the file and import that file into the Intermediate Certification AUthorities tab Then go back to the Personal Store tab Double click the certificate Click the certification path tab There should be 4 certificates in the certificate hierarchy at this stage Highlight the certificate in the Personal Store Click on Export Click 'Yes, export private key' Click Next Put a tick in the first checkbox only, not the other two Finish the wizard Rename the PFX file you create to have a p12 extension Use the new .p12 file in Tomcat - End forwarded message - -- Lutz Jaenicke jaeni...@openssl.org OpenSSL Project http://www.openssl.org/~jaenicke/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Link errors when building openssl 0.9.8e on Mac OS
I am also having the same problem. Nobody has replied??? -- View this message in context: http://old.nabble.com/Link-errors-when-building-openssl-0.9.8e-on-Mac-OS-tp27151830p30948006.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: Problem with multiple level CA
No, should I? If I'm going to generate user keys-certificates that will be signed by SIGNING CA certificate, should I force all users to install ROOT CA as trusted certificate? On Thu, Feb 17, 2011 at 11:08 AM, Federico Berton wrote: > Have you added the ROOTCA certificate in the trusted root certificate? > > FEDERICO BERTON > AREA SVILUPPO > > Via Europa, 20 > 35015 Galliera Veneta (PD) > TEL. 049.9988200 FAX 049.9471337 > http://www.trivenet.it > > > -Messaggio originale- > Da: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] > Per conto di Tanya Lozovaya > Inviato: giovedì 17 febbraio 2011 09:49 > A: d...@deadhat.com; openssl-users@openssl.org > Oggetto: Re: Problem with multiple level CA > > I tried to open crt file on different computers and I got different errors: > > on Windows 7: The issuer of this certificate could not be found. > on Windows 2003: This certificate has an nonvalid digital signature. > > Do anybody know how I can make the computers to "think" that self-signed > "ROOT CA" certificate is valid (trusted) and it is the parent for "SIGNING > CA"? > > Thanks, > -- > Tanya. > > On Wed, Feb 16, 2011 at 10:19 PM, wrote: >> Yes, I used your config files. >> >> With Windows 2003 (Which is a version of Windows 2000), you don't have >> RSA2048 support, so it can't verify the signature. >> >> However if you verify the signature in openssl, it is fine, since >> openssl supports RSA2048. >> >> E.G.: >> [root@dj-desk1 ~]# openssl verify -CAfile root-ca.crt signing-ca.crt >> signing-ca.crt: OK >> >> >> >>> I use Windows 2003. >>> >>> Did you try my config files? >>> >>> Thanks, >>> -- >>> Tanya. >>> >>> On Wed, Feb 16, 2011 at 8:15 PM, wrote: It worked for me. Are you using Windows XP? Except for a recent update, XP didn't support 2048 RSA. Regards, David > Hi guys, > > I have tried to configure multiple level CA structure: ROOT CA -> > SIGNING CA -> Users certificates I use RootSSL.cnf file and these > commands to generate root certificate: > openssl genrsa -des3 -out root-ca.key 2048 > openssl req -new -x509 -days 3650 -key root-ca.key -out > root-ca.crt -config RootSSL.cnf > > In order to generate intermediate CA I use OpenSSL.cnf file and > these > commands: > openssl genrsa -des3 -out signing-ca.key 2048 > openssl req -new -days 1095 -key signing-ca.key -out > signing-ca.csr -config openssl.cnf > openssl ca -config openssl.cnf -name CA_root -extensions > v3_ca -out signing-ca.crt -infiles signing-ca.csr > > As the result I have OK root certificate, but I see error message > for signing certificate: "This certificate has an nonvalid digital > signature." > > Can somebody advise me what I do wrong? > > Thanks, > -- > Tanya Lozovaya. > >>> >>> >>> >>> -- >>> Tanya Lozovaya. >>> >> >> > > > > -- > Tanya Lozovaya. > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org > -- Tanya Lozovaya. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
R: Problem with multiple level CA
Have you added the ROOTCA certificate in the trusted root certificate? FEDERICO BERTON AREA SVILUPPO Via Europa, 20 35015 Galliera Veneta (PD) TEL. 049.9988200 FAX 049.9471337 http://www.trivenet.it -Messaggio originale- Da: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] Per conto di Tanya Lozovaya Inviato: giovedì 17 febbraio 2011 09:49 A: d...@deadhat.com; openssl-users@openssl.org Oggetto: Re: Problem with multiple level CA I tried to open crt file on different computers and I got different errors: on Windows 7: The issuer of this certificate could not be found. on Windows 2003: This certificate has an nonvalid digital signature. Do anybody know how I can make the computers to "think" that self-signed "ROOT CA" certificate is valid (trusted) and it is the parent for "SIGNING CA"? Thanks, -- Tanya. On Wed, Feb 16, 2011 at 10:19 PM, wrote: > Yes, I used your config files. > > With Windows 2003 (Which is a version of Windows 2000), you don't have > RSA2048 support, so it can't verify the signature. > > However if you verify the signature in openssl, it is fine, since > openssl supports RSA2048. > > E.G.: > [root@dj-desk1 ~]# openssl verify -CAfile root-ca.crt signing-ca.crt > signing-ca.crt: OK > > > >> I use Windows 2003. >> >> Did you try my config files? >> >> Thanks, >> -- >> Tanya. >> >> On Wed, Feb 16, 2011 at 8:15 PM, wrote: >>> It worked for me. >>> >>> Are you using Windows XP? Except for a recent update, XP didn't >>> support >>> 2048 RSA. >>> >>> Regards, >>> David >>> >>> Hi guys, I have tried to configure multiple level CA structure: ROOT CA -> SIGNING CA -> Users certificates I use RootSSL.cnf file and these commands to generate root certificate: openssl genrsa -des3 -out root-ca.key 2048 openssl req -new -x509 -days 3650 -key root-ca.key -out root-ca.crt -config RootSSL.cnf In order to generate intermediate CA I use OpenSSL.cnf file and these commands: openssl genrsa -des3 -out signing-ca.key 2048 openssl req -new -days 1095 -key signing-ca.key -out signing-ca.csr -config openssl.cnf openssl ca -config openssl.cnf -name CA_root -extensions v3_ca -out signing-ca.crt -infiles signing-ca.csr As the result I have OK root certificate, but I see error message for signing certificate: "This certificate has an nonvalid digital signature." Can somebody advise me what I do wrong? Thanks, -- Tanya Lozovaya. >>> >>> >> >> >> >> -- >> Tanya Lozovaya. >> > > -- Tanya Lozovaya. __ 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
Re: Problem with multiple level CA
I tried to open crt file on different computers and I got different errors: on Windows 7: The issuer of this certificate could not be found. on Windows 2003: This certificate has an nonvalid digital signature. Do anybody know how I can make the computers to "think" that self-signed "ROOT CA" certificate is valid (trusted) and it is the parent for "SIGNING CA"? Thanks, -- Tanya. On Wed, Feb 16, 2011 at 10:19 PM, wrote: > Yes, I used your config files. > > With Windows 2003 (Which is a version of Windows 2000), you don't have > RSA2048 support, so it can't verify the signature. > > However if you verify the signature in openssl, it is fine, since openssl > supports RSA2048. > > E.G.: > [root@dj-desk1 ~]# openssl verify -CAfile root-ca.crt signing-ca.crt > signing-ca.crt: OK > > > >> I use Windows 2003. >> >> Did you try my config files? >> >> Thanks, >> -- >> Tanya. >> >> On Wed, Feb 16, 2011 at 8:15 PM, wrote: >>> It worked for me. >>> >>> Are you using Windows XP? Except for a recent update, XP didn't support >>> 2048 RSA. >>> >>> Regards, >>> David >>> >>> Hi guys, I have tried to configure multiple level CA structure: ROOT CA -> SIGNING CA -> Users certificates I use RootSSL.cnf file and these commands to generate root certificate: openssl genrsa -des3 -out root-ca.key 2048 openssl req -new -x509 -days 3650 -key root-ca.key -out root-ca.crt -config RootSSL.cnf In order to generate intermediate CA I use OpenSSL.cnf file and these commands: openssl genrsa -des3 -out signing-ca.key 2048 openssl req -new -days 1095 -key signing-ca.key -out signing-ca.csr -config openssl.cnf openssl ca -config openssl.cnf -name CA_root -extensions v3_ca -out signing-ca.crt -infiles signing-ca.csr As the result I have OK root certificate, but I see error message for signing certificate: "This certificate has an nonvalid digital signature." Can somebody advise me what I do wrong? Thanks, -- Tanya Lozovaya. >>> >>> >> >> >> >> -- >> Tanya Lozovaya. >> > > -- Tanya Lozovaya. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
