SHA-1 Hash Problem with i2d_Pubkey()
Hi!
I was to send SHA1 hash of my public to some peer.
For that i have written a function:
EVP_PKEY * ReadPublicKey(const char *certfile)
{
FILE *fp = fopen (certfile, r);
X509 *x509;
EVP_PKEY *pkey;
if (!fp)
return NULL;
x509 = PEM_read_X509(fp, NULL, 0, NULL);
if (x509 == NULL)
{
ERR_print_errors_fp (stderr);
return NULL;
}
fclose (fp);
pkey=X509_extract_key(x509);
X509_free(x509);
if (pkey == NULL)
ERR_print_errors_fp (stderr);
return pkey;
}
Then, I am extracting the public key in a buffer:
pubKey = ReadPublicKey(PUBFILE);
if(!pubKey)
{
fprintf(stderr,Error: can't load public key);
exit(1);
}
issuer_pubkey_len = i2d_PUBKEY(pubKey, NULL);
issuer_pubkey = malloc(issuer_pubkey_len);
i2d_PUBKEY(pubKey, issuer_pubkey);
memory_dump(issuer_pubkey, issuer_pubkey, issuer_pubkey_len);
The problem, is issuer_pubkey buffer is different each time, I run the my
application using same code.
To debug the problem, i created a separate test code, just reading the
issuer cert in .pem format and reading the pubkey in buffer, the buffer is
same each time i run test code as expected.
How come pubkey in a buffer can be different each time in my application ?
Is this some -lcrypto linking problem ?
I have also debugged for memory corruption. It is not present.
Please provide some pointers.
Thanks for the help in advance.
Best Regards,
Raj
example: key derivation
Hello, i am wondering how key derivation in openssl works, I got openssl enc -des -P -k 'admin' -nosalt key=21232F297A57A5A7 iv =43894A0E4A801FC3 as far i understand the documentation, in this setting the key and iv are just taken from md5(admin)=456b7016a916a4b178dd72b947c152b7 but obviously there has to be some magic. Could someone give me a hint for good documentation ( != source )? stephan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Custom certificate
Hi Please how can i edit a CSR? Regards, Emmanuel Guiton wrote: Hello, Thank you, it works like a charm. Just have to solve the date problem, now. - Emmanuel Marek Marcola wrote: Hello, In the issuer and subject fields, I must include a dnQualifier which is a thumbprint of the corresponding public key, that is to say a SHA-1 hash of the contents of the SubjectPublicKey BIT STRING in the SubjectPublicKeyInfo field (excluding the DER tag, length, and number of unused bits count in the DER header for the BIT STRING). How can I do that? It is not very complicated. Suppose you have Certificate Signing Request file (say req.pem). You should first extract public key to some file: $ openssl req -in req.pem -pubkey -noout req_pub_key.pem Next from this pub key you should extract ASN.1 SEQUENCE of INTEGER n and INTEGER e. To display: $ openssl asn1parse -in req_pub_key.pem 0:d=0 hl=3 l= 159 cons: SEQUENCE 3:d=1 hl=2 l= 13 cons: SEQUENCE 5:d=2 hl=2 l= 9 prim: OBJECT:rsaEncryption 16:d=2 hl=2 l= 0 prim: NULL 18:d=1 hl=3 l= 141 prim: BIT STRING $ openssl asn1parse -in req_pub_key.pem -strparse 18 0:d=0 hl=3 l= 137 cons: SEQUENCE 3:d=1 hl=3 l= 129 prim: INTEGER :E3295A7F558C3D78D3 ... 135:d=1 hl=2 l= 3 prim: INTEGER :010001 and to save in DER format: $ openssl asn1parse -in req_pub_key.pem -strparse 18 -noout \ -out pub_key.der $ openssl asn1parse -in pub_key.der -inform DER 0:d=0 hl=3 l= 137 cons: SEQUENCE 3:d=1 hl=3 l= 129 prim: INTEGER :E3295A7F558C3D78D3 ... 135:d=1 hl=2 l= 3 prim: INTEGER :010001 and you should make digest of this file: $ cat pub_key.der | openssl dgst -sha1 f8aa13223180643bf899eaa6faac94c2aa7bdd73 Best regards, -- 165, avenue Aristide Briand 94230 Cachan Tel/fax: 01 46 63 29 28 E-mail: emmanuel.gui...@neuf.fr __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- View this message in context: http://old.nabble.com/Custom-certificate-tp4593172p29673140.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
EDIT FILDS CSR
Please, help me: How can I edit a CSR? Thanks, -- View this message in context: http://old.nabble.com/EDIT-FILDS-CSR-tp29673141p29673141.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
Bad decrypt error with aes128
hello all. I am trying to use AES128ctr mode in openssl. I am using my hardware driver for the same for encryption and decryption through openssl. Encryption is working fine but during decryption it gives bad decryption error. I am using the following commands openssl enc -e -in infile -out encfile -aes-128-ctr openssl enc -d -in encfile -out decfile -aes-128-ctr and i get the error when i try to execute the 2nd command bad decrypt 1075934680:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:498: i am stuck here from many days please help me.. thanks in advance
Re: SHA-1 Hash Problem with i2d_Pubkey()
On 9/12/2010 11:38 PM, Raj Singh wrote: issuer_pubkey_len = i2d_PUBKEY(pubKey, NULL); issuer_pubkey = malloc(issuer_pubkey_len); i2d_PUBKEY(pubKey, issuer_pubkey); memory_dump(issuer_pubkey, issuer_pubkey, issuer_pubkey_len); The problem, is issuer_pubkey buffer is different each time, I run the my application using same code. Umm, you forgot to save the original issuer_pubkey. After the call to i2d_PUBKEY, issuer_pubkey points elsewhere. Try: issuer_pubkey_len = i2d_PUBKEY(pubKey, NULL); issuer_pubkey = malloc(issuer_pubkey_len); foo=issuer_pubkey; i2d_PUBKEY(pubKey, foo); memory_dump(issuer_pubkey, issuer_pubkey, issuer_pubkey_len); DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Sign a file using OpenSSL and .cer files
Dear Expert, I am unable to sign using the following command openssl smime -sign -in input filename -out signature filename -outform pem -inkey private key -signer certificate Where input filename = 1.txt output filename = 2.txt certificate = abc.p7b Content of 1.txt is as follow This is testing file for attachement. I am getting following error. Loading 'screen' into random state - done unable to load certificate 2140:error:0906D06C:PEM routines:PEM_read_bio:no start line:.\crypto\pem\pem_lib.c:663:Expecting: TRUSTED CERTIFICATE Can't read signer certificate file abc.p7b Can you please help me out for the same? -- View this message in context: http://old.nabble.com/Sign-a-file-using-OpenSSL-and-.cer-files-tp29695012p29695012.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: EDIT FIELDS ON CSR
On September 11, 2010 10:58:44 am kummers wrote: Please, help me: How can I edit a CSR, i neew to chane the filds, for axample. edit the common name, I've been looking but have not found anything in the forum You cannot edit a CSR - it is a signed structure - why don't you just re- generate it with the correct values? Also - there is absolutely NOTHING that says that you have to keep the information in a CSR when you generate the X.509 certificate - so if you need to change the Subject DN so that when you generate the Certificate get a different value, just tell OpenSSL (or whatever CA software you are using) to do that. (of course, the caveat with the above is that you need a good way to bind the public key in the PKCS#10 or SPKAC structure with the subscriber named in the Subject of the X.509, but you weren't just trusting a self asserted value in a CSR to prove that, were you? :) Have fun! -- Patrick Patterson President and Chief PKI Architect, Carillon Information Security Inc. http://www.carillon.ca __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: generating keys from passwords
i am wondering how key derivation in openssl works, I got
openssl enc -des -P -k 'admin' -nosalt
key=21232F297A57A5A7
iv =43894A0E4A801FC3
as far i understand the documentation, in this setting the
key and iv are
just taken from
md5(admin)=456b7016a916a4b178dd72b947c152b7
md5(admin)= 21232f297a57a5a743894a0e4a801fc3
md5(admin PLUS NEWLINE)= what you got
Thanks, for your reply - by default nano adds a newline to a file, so i
got bad results.
The next step is to understand the insertion of salt. I tried to
understand 'enc.c' and 'evp_key.c', for key derivation EVP_BytesToKey() is
called. I am not familiar with things like MDcontexts; BIOs etc, so i
don't understand it very well. But according to its documentation it
computes
D_0 = {}
D_i = hash(d_{i-1}||data||salt)
After that the key and iv are taken from D_1, D_2, ...
For DES it would be enough to generate D_1.
data = 'admin'
As salt i use '', so 'Salted__' is passed
to EVP_BytesToKey - Anyway i cant reproduce
openssl enc -des -k 'admin' -P -S
salt=
key=752B559CFABA36F6
iv =9B6A524533353200
by hand. A Similar problem with
openssl enc -blowfish -k 'admin' -P -nosalt
key=21232F297A57A5A743894A0E4A801FC3 = md5(admin)
iv =7BED69E4F5F533BE != md5(md5(admin)||admin)..
can someone give me some hints..
stephan
ps: sorry for the double postings.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: SHA-1 Hash Problem with i2d_Pubkey()
Hi, To: openssl-...@openssl.org, openssl-users@openssl.org One list really would have been enough ... (snipp) issuer_pubkey = malloc(issuer_pubkey_len); i2d_PUBKEY(pubKey, issuer_pubkey); The fact that you need to pass the _address_ of issuer_pubkey hints at amodification of it's content, doesn't it? IIRC, it's going to point at the _end_ of the buffer you passed into i2d_PUBKEY. memory_dump(issuer_pubkey, issuer_pubkey, issuer_pubkey_len); So, here you're dumping what there is in memory right _after_ your key.. The problem, is issuer_pubkey buffer is different each time, I run the my application using same code. Since you're printing uninitialized memory, this shouldn't be a surprise any more. ;-) HTH, Stefan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
x509_verify_cert() succeeds only once
Hi there,
I wrote a server-like program in charge of verifying incoming users'
X.509 certificates
using a list of CAs and their associated CRLs.
The program uses a global X509_STORE to hold CA certificates and CRLs.
The global X509_STORE is built during the initialization of the server
using X509_STORE_add_cert() and X509_STORE_add_crl() functions.
The verification of each user certificate uses the following code:
bool verify_certificate ( X509 *pCert )
{
// Global variable: X509_STORE *g_pStore
X509_STORE_CTX *pContext = X509_STORE_CTX_new();
if ( ! X509_STORE_CTX_init(pContext, g_pStore, pCert,NULL)) return
false;
// Make sure the issuing CA is known
X509_OBJECT xObj; memset(xObj,0,sizeof(X509_OBJECT));
int iErr = X509_STORE_get_by_subject(pContext,
X509_LU_X509,
X509_get_issuer_name(pCert),
xObj);
if ( iErr = 0 ) {
printf(X509_STORE_get_by_subject: %s\n,
X509_verify_cert_error_string(pContext-error));
OPENSSL_free(pContext);
return false;
}
// Verify certificate using CA Certs and CRL in the STORE
int iErr = x509_verify_cert(pContext);
if ( iErr != 1 )
{
printf(x509_verify_cert: %s\n,
X509_verify_cert_error_string(pContext-error));
OPENSSL_free(pContext);
return false;
}
// Make sure certificate is not in one CRL
X509_OBJECT xCRL; memset(xCRL,0,sizeof(X509_OBJECT));
iErr = X509_STORE_get_by_subject(pContext,
X509_LU_CRL,
X509_get_issuer_name(pCert),
xCRL);
X509_CRL *pCRL = xCRL.data.crl;
if (iErr 0 pCRL)
{
STACK_OF(X509_REVOKED) *pRevoked = X509_CRL_get_REVOKED(pCRL);
if ( sk_X509_REVOKED_num(pRevoked) 0 )
{
X509_REVOKED revoked; revoked.serialNumber =
X509_get_serialNumber(pCert);
int rv = sk_X509_REVOKED_find(pRevoked, revoked);
if ( sk_X509_REVOKED_find(pRevoked, revoked) = 0 )
{
OPENSSL_free(pContext);
return false;
}
}
}
OPENSSL_free(pContext);
}
The above function works only once: the second time I invoke the function
(even with the same X.509 user's certificate!), it always fails with error:
X509_V_ERR_CERT_SIGNATURE_FAILURE.
If I destroy and rebuild the global X509_STORE before verifying each
certificate,
then the x509_verify_cert() function works as expected.
I tried to track changes inside the X509_STORE during x509_verify_cert()
but to no avail. Only the g_pStore-objs.sorted member seems to change when
X509_STORE_get_by_subject() is invoked for the first time.
What did I miss when using X509_STORE[_CTX]?
Thanks in advance for your help,
--
Jacques.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: wrong ELF class: ELFCLASS32
Solaris 9 117560-06 111* patch for libm.so, I think might fix this. Do a search on sunsolve. --- BISHT, SEEMANT (SEEMANT) seemant.bi...@alcatel-lucent.com wrote: class=459000609-17082010Can you please tell me how to compile openssl li brary in 64-bit type? As when compiling the openssl, and checking /DIV class=459000609-17082010 ; class=459000609-17082010GNM056 sdefile bio_ssl.obio_ssl.o: ELF 32-bit MSB relocatable SPARC32PLUS Version 1, V8+ RequiredGNM056 sde class=459000609-17082010I need it to be in 64 bit as I need to link this library with my existing .so that is in 64 bit. class=459000609-17082010My .so: class=459000609-17082010 G NM056 sdefile libsib_velizy_generic_uns_HTTPSClient.solibsib_velizy_generic_uns_HTTPS Client.so: ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not strippedGNM056 sde FONT color=#ffAs compiling my .so with openssl .so. I am having error: class=459000609-17082010 2 class=459000609-17082010ld: fatal: file /openssl-0.9.8o/ssl/bio_ssl.: wrong ELF class: ELFCLASS32 FONT color=#00 size=2 FONT color=#00 size=2Please show me the way. Thanks. FONT color=#00 size=2 color=#ff FONT color=#00 size=2 FONT color=purple style=FONT-SIZE: 10pt; COLOR: purple; FONT-FAMILY: VerdanaThan ks Regards, color=purple style=FONT-SIZE: 10pt; COLOR: purple; FONT-FAMILY: VerdanaSeem ant Bisht. style=FONT-SIZE: 10pt; COLOR: purple; FONT-FAMILY: Verdana face=Courier NewAlcatel Ph. No. +91-124-4133453Mobile: +919810063317 style=FONT-SIZE: 10pt; COLOR: gray; FONT-FAMILY: 'Arial Narrow' face=Courier NewAlcatel-Lucent India style=FONT-SIZE: 10pt; COLOR: gray; FONT-FAMILY: 'Arial Narrow' style=FONT-SIZE: 10pt; COLOR: gray; FONT-FAMILY: 'Arial Narrow' class=582270606-01062009Building No.1, Fourth Floor, Seat No.59 style=FONT-SIZE: 10pt; COLOR: gray; FONT-FAMILY: 'Arial Narrow' style=FONT-SIZE: 10pt; COLOR: gray; FONT-FAMILY: 'Arial Narrow' face=Courier NewPlot No.406, Udyog Vihar, Phase III style=FONT-SIZE: 10pt; COLOR: gray; FONT-FAMILY: 'Arial Narrow' style=FONT-SIZE: 10pt; COLOR: gray; FONT-FAMILY: 'Arial Narrow' face=Courier New color=#808080 size=2Gurgaon 122016 /DIV style=FONT-WEIGHT: bold; FONT-SIZE: 24pt; COLOR: green; FONT-FAMILY: Web dingsP face=Times New Roman color=navy size=3 style=COLOR: navy size=1 style=FONT-SIZE: 8pt; COLOR: green; FONT-FAMILY: TahomaThink of the environmental impact before printing class=459000609-17082010 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Intermediate root CA's -- lost and confused :(
We just installed our first Thawte cert that uses their intermediate CA's, and it's not going as smoothly as I'd like. It's installed on an Apache server with mod_ssl, and I added the intermediate root CA's to the apache config with the SSLCACertificateFile directive. Web browsers seem happy with it, they validate the cert with no errors. I'm having trouble with command line tools under Linux though, including openssl itself. openssl won't correctly validate the cert: $ openssl s_client -CAfile /etc/ssl/certs/Thawte_Premium_Server_CA.pem -connect strategic.wiki.csupomona.edu:443 CONNECTED(0003) depth=0 /C=US/ST=California/L=Pomona/O=California State Polytechnic University, Pomona/OU=I(ampersand)IT Systems/CN=strategic.wiki.csupomona.edu verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /C=US/ST=California/L=Pomona/O=California State Polytechnic University, Pomona/OU=I(ampersand)IT Systems/CN=strategic.wiki.csupomona.edu verify error:num=27:certificate not trusted verify return:1 depth=0 /C=US/ST=California/L=Pomona/O=California State Polytechnic University, Pomona/OU=I(ampersand)IT Systems/CN=strategic.wiki.csupomona.edu verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Pomona/O=California State Polytechnic University, Pomona/OU=I(ampersand)IT Systems/CN=strategic.wiki.csupomona.edu i:/C=US/O=Thawte, Inc./CN=Thawte SSL CA --- Server certificate -BEGIN CERTIFICATE- [...] It works fine, OTOH, with a cert signed directly by the Thawte Premium Server CA: $ openssl s_client -CAfile /etc/ssl/certs/Thawte_Premium_Server_CA.pem -connect www.csupomona.edu:443 CONNECTED(0003) depth=1 /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailaddress=premium-ser...@thawte.com verify return:1 depth=0 /C=US/ST=California/L=Pomona/O=California State Polytechnic University, Pomona/CN=www.csupomona.edu verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Pomona/O=California State Polytechnic University, Pomona/CN=www.csupomona.edu i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailaddress=premium-ser...@thawte.com 1 s:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailaddress=premium-ser...@thawte.com i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailaddress=premium-ser...@thawte.com --- Server certificate -BEGIN CERTIFICATE- [...] As I mentioned, web browsers work fine, and I think the server is configured correctly. Also, gnutls-cli works fine on the same box: $ gnutls-cli --x509cafile /etc/ssl/certs/Thawte_Premium_Server_CA.pem strategic.wiki.csupomona.edu -p 443 Processed 1 CA certificate(s). Resolving 'strategic.wiki.csupomona.edu'... Connecting to '134.71.247.55:443'... - Ephemeral Diffie-Hellman parameters - Using prime: 1024 bits - Secret key: 1021 bits - Peer's public key: 1024 bits - Certificate type: X.509 - Got a certificate list of 3 certificates. - Certificate[0] info: - subject `C=US,ST=California,L=Pomona,O=California State Polytechnic University\, Pomona,OU=I(ampersand)IT Systems,CN=strategic.wiki.csupomona.edu', issuer `C=US,O=Thawte\, Inc.,CN=Thawte SSL CA', RSA key 2048 bits, signed using RSA-SHA1, activated `2010-09-10 00:00:00 UTC', expires `2011-09-10 23:59:59 UTC', SHA-1 fingerprint `57292bcd7541c56c7b664705f0192b43a927056c' - Certificate[1] info: - subject `C=US,O=Thawte\, Inc.,CN=Thawte SSL CA', issuer `C=US,O=thawte\, Inc.,OU=Certification Services Division,OU=(c) 2006 thawte\, Inc. - For authorized use only,CN=thawte Primary Root CA', RSA key 2048 bits, signed using RSA-SHA1, activated `2010-02-08 00:00:00 UTC', expires `2020-02-07 23:59:59 UTC', SHA-1 fingerprint `73e42686657aece354fbf685712361658f2f4357' - Certificate[2] info: - subject `C=US,O=thawte\, Inc.,OU=Certification Services Division,OU=(c) 2006 thawte\, Inc. - For authorized use only,CN=thawte Primary Root CA', issuer `C=ZA,ST=Western Cape,L=Cape Town,O=Thawte Consulting cc,OU=Certification Services Division,CN=Thawte Premium Server CA,email=premium-ser...@thawte.com', RSA key 2048 bits, signed using RSA-SHA1, activated `2006-11-17 00:00:00 UTC', expires `2020-12-30 23:59:59 UTC', SHA-1 fingerprint `1fa490d1d4957942cd23545f6e823d796ea2' - The hostname in the certificate matches
RE: Intermediate root CA's -- lost and confused :(
From the openssl s_client log it looks like the server is not sending the whole certificate chain. You should be seeing something like: root cert intermediate cert your cert I am not familiar with apache, but from the documentation at http://www.apache-ssl.org/docs.html#SSLCACertificateFile, my guess is that you have not added all the intermediate roots to the CACertificatesFile, hence apache is having trouble assembling the certificate chain. I recommend adding all the intermediate certs and the root into the CA file and give it a try. Looking at the web site, you should add the following: Thawte SSL CA, thawte Primary Root CA, Thawte Premium Server CA. You should be able to find these certs on Thawte's web site: https://www.thawte.com/roots/index.html Ashish. -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Paul B. Henson Sent: Monday, September 13, 2010 12:58 PM To: openssl-users@openssl.org Subject: Intermediate root CA's -- lost and confused :( We just installed our first Thawte cert that uses their intermediate CA's, and it's not going as smoothly as I'd like. It's installed on an Apache server with mod_ssl, and I added the intermediate root CA's to the apache config with the SSLCACertificateFile directive. Web browsers seem happy with it, they validate the cert with no errors. I'm having trouble with command line tools under Linux though, including openssl itself. openssl won't correctly validate the cert: $ openssl s_client -CAfile /etc/ssl/certs/Thawte_Premium_Server_CA.pem -connect strategic.wiki.csupomona.edu:443 CONNECTED(0003) depth=0 /C=US/ST=California/L=Pomona/O=California State Polytechnic University, Pomona/OU=I(ampersand)IT Systems/CN=strategic.wiki.csupomona.edu verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /C=US/ST=California/L=Pomona/O=California State Polytechnic University, Pomona/OU=I(ampersand)IT Systems/CN=strategic.wiki.csupomona.edu verify error:num=27:certificate not trusted verify return:1 depth=0 /C=US/ST=California/L=Pomona/O=California State Polytechnic University, Pomona/OU=I(ampersand)IT Systems/CN=strategic.wiki.csupomona.edu verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Pomona/O=California State Polytechnic University, Pomona/OU=I(ampersand)IT Systems/CN=strategic.wiki.csupomona.edu i:/C=US/O=Thawte, Inc./CN=Thawte SSL CA --- Server certificate -BEGIN CERTIFICATE- [...] It works fine, OTOH, with a cert signed directly by the Thawte Premium Server CA: $ openssl s_client -CAfile /etc/ssl/certs/Thawte_Premium_Server_CA.pem -connect www.csupomona.edu:443 CONNECTED(0003) depth=1 /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailaddress=premium-ser...@thawte.com verify return:1 depth=0 /C=US/ST=California/L=Pomona/O=California State Polytechnic University, Pomona/CN=www.csupomona.edu verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Pomona/O=California State Polytechnic University, Pomona/CN=www.csupomona.edu i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailaddress=premium-ser...@thawte.com 1 s:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailaddress=premium-ser...@thawte.com i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailaddress=premium-ser...@thawte.com --- Server certificate -BEGIN CERTIFICATE- [...] As I mentioned, web browsers work fine, and I think the server is configured correctly. Also, gnutls-cli works fine on the same box: $ gnutls-cli --x509cafile /etc/ssl/certs/Thawte_Premium_Server_CA.pem strategic.wiki.csupomona.edu -p 443 Processed 1 CA certificate(s). Resolving 'strategic.wiki.csupomona.edu'... Connecting to '134.71.247.55:443'... - Ephemeral Diffie-Hellman parameters - Using prime: 1024 bits - Secret key: 1021 bits - Peer's public key: 1024 bits - Certificate type: X.509 - Got a certificate list of 3 certificates. - Certificate[0] info: - subject `C=US,ST=California,L=Pomona,O=California State Polytechnic University\, Pomona,OU=I(ampersand)IT Systems,CN=strategic.wiki.csupomona.edu', issuer `C=US,O=Thawte\, Inc.,CN=Thawte SSL CA', RSA key 2048 bits, signed using RSA-SHA1, activated `2010-09-10 00:00:00 UTC', expires `2011-09-10
Re: Intermediate root CA's -- lost and confused :(
Be careful you are not checking the web server from a browser that has the intermediate certificate installed. Obtain the root certificate - and only the root certificate - that is likely to be present in a random user's browser and save it as thawte_root_cert.pem openssl s_client -verify 10 -CAfile thawte_root_cert.pem -connect strategic.wiki.csupomona.edu:443 On Sep 13, 2010, at 12:58 PM, Paul B. Henson wrote: We just installed our first Thawte cert that uses their intermediate CA's, and it's not going as smoothly as I'd like. It's installed on an Apache server with mod_ssl, and I added the intermediate root CA's to the apache config with the SSLCACertificateFile directive. Web browsers seem happy with it, they validate the cert with no errors. I'm having trouble with command line tools under Linux though, including openssl itself. openssl won't correctly validate the cert: $ openssl s_client -CAfile /etc/ssl/certs/Thawte_Premium_Server_CA.pem -connect strategic.wiki.csupomona.edu:443 CONNECTED(0003) depth=0 /C=US/ST=California/L=Pomona/O=California State Polytechnic University, Pomona/OU=I(ampersand)IT Systems/CN=strategic.wiki.csupomona.edu verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /C=US/ST=California/L=Pomona/O=California State Polytechnic University, Pomona/OU=I(ampersand)IT Systems/CN=strategic.wiki.csupomona.edu verify error:num=27:certificate not trusted verify return:1 depth=0 /C=US/ST=California/L=Pomona/O=California State Polytechnic University, Pomona/OU=I(ampersand)IT Systems/CN=strategic.wiki.csupomona.edu verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Pomona/O=California State Polytechnic University, Pomona/OU=I(ampersand)IT Systems/CN=strategic.wiki.csupomona.edu i:/C=US/O=Thawte, Inc./CN=Thawte SSL CA --- Server certificate -BEGIN CERTIFICATE- [...] It works fine, OTOH, with a cert signed directly by the Thawte Premium Server CA: $ openssl s_client -CAfile /etc/ssl/certs/Thawte_Premium_Server_CA.pem -connect www.csupomona.edu:443 CONNECTED(0003) depth=1 /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailaddress=premium-ser...@thawte.com verify return:1 depth=0 /C=US/ST=California/L=Pomona/O=California State Polytechnic University, Pomona/CN=www.csupomona.edu verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Pomona/O=California State Polytechnic University, Pomona/CN=www.csupomona.edu i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailaddress=premium-ser...@thawte.com 1 s:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailaddress=premium-ser...@thawte.com i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailaddress=premium-ser...@thawte.com --- Server certificate -BEGIN CERTIFICATE- [...] As I mentioned, web browsers work fine, and I think the server is configured correctly. Also, gnutls-cli works fine on the same box: $ gnutls-cli --x509cafile /etc/ssl/certs/Thawte_Premium_Server_CA.pem strategic.wiki.csupomona.edu -p 443 Processed 1 CA certificate(s). Resolving 'strategic.wiki.csupomona.edu'... Connecting to '134.71.247.55:443'... - Ephemeral Diffie-Hellman parameters - Using prime: 1024 bits - Secret key: 1021 bits - Peer's public key: 1024 bits - Certificate type: X.509 - Got a certificate list of 3 certificates. - Certificate[0] info: - subject `C=US,ST=California,L=Pomona,O=California State Polytechnic University\, Pomona,OU=I(ampersand)IT Systems,CN=strategic.wiki.csupomona.edu', issuer `C=US,O=Thawte\, Inc.,CN=Thawte SSL CA', RSA key 2048 bits, signed using RSA-SHA1, activated `2010-09-10 00:00:00 UTC', expires `2011-09-10 23:59:59 UTC', SHA-1 fingerprint `57292bcd7541c56c7b664705f0192b43a927056c' - Certificate[1] info: - subject `C=US,O=Thawte\, Inc.,CN=Thawte SSL CA', issuer `C=US,O=thawte\, Inc.,OU=Certification Services Division,OU=(c) 2006 thawte\, Inc. - For authorized use only,CN=thawte Primary Root CA', RSA key 2048 bits, signed using RSA-SHA1, activated `2010-02-08 00:00:00 UTC', expires `2020-02-07 23:59:59 UTC', SHA-1 fingerprint `73e42686657aece354fbf685712361658f2f4357' - Certificate[2] info: - subject `C=US,O=thawte\,
RE: Intermediate root CA's -- lost and confused :(
On Mon, 13 Sep 2010, Ashish Thapliyal wrote: From the openssl s_client log it looks like the server is not sending the whole certificate chain. You should be seeing something like: root cert intermediate cert your cert I am not familiar with apache, but from the documentation at http://www.apache-ssl.org/docs.html#SSLCACertificateFile, my guess is that you have not added all the intermediate roots to the CACertificatesFile Thanks for the response. I'm pretty sure the web server is configured correctly. Before I added the CACertificatesFile directive, I was getting security errors from firefox/IE/et al; whereas after I added it web browsers seems to be working fine. Also, gnutls-client works correctly and lists the entire CA chain, which would also seem to indicate the server is supplying them. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Intermediate root CA's -- lost and confused :(
On Mon, 13 Sep 2010, Chris wrote: Be careful you are not checking the web server from a browser that has the intermediate certificate installed. I initially installed just the new cert on the web server, and the web browsers were generating cert security errors. I then went back and added the SSLCACertificateFile directive and the intermediate certs on the server; at that point the web browsers were happy. This leads me to believe the web server is correctly configured. openssl s_client -verify 10 -CAfile thawte_root_cert.pem -connect strategic.wiki.csupomona.edu:443 I had output from a similar command in my initial email without the verify option, it still fails with it: - $ openssl s_client -verify 10 -CAfile /etc/ssl/certs/Thawte_Premium_Server_CA.pem -connect strategic.wiki.csupomona.edu:443 verify depth is 10 CONNECTED(0003) depth=0 /C=US/ST=California/L=Pomona/O=California State Polytechnic University, Pomona/OU=I(ampersand)IT Systems/CN=strategic.wiki.csupomona.edu verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /C=US/ST=California/L=Pomona/O=California State Polytechnic University, Pomona/OU=I(ampersand)IT Systems/CN=strategic.wiki.csupomona.edu verify error:num=27:certificate not trusted verify return:1 depth=0 /C=US/ST=California/L=Pomona/O=California State Polytechnic University, Pomona/OU=I(ampersand)IT Systems/CN=strategic.wiki.csupomona.edu verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Pomona/O=California State Polytechnic University, Pomona/OU=I(ampersand)IT Systems/CN=strategic.wiki.csupomona.edu i:/C=US/O=Thawte, Inc./CN=Thawte SSL CA --- Server certificate -BEGIN CERTIFICATE- [...] - gnutls-client on the same box works fine, listing the entire certificate chain: - $ gnutls-cli --x509cafile /etc/ssl/certs/Thawte_Premium_Server_CA.pem strategic.wiki.csupomona.edu -p 443 Processed 1 CA certificate(s). Resolving 'strategic.wiki.csupomona.edu'... Connecting to '134.71.247.55:443'... - Ephemeral Diffie-Hellman parameters - Using prime: 1024 bits - Secret key: 1023 bits - Peer's public key: 1024 bits - Certificate type: X.509 - Got a certificate list of 3 certificates. - Certificate[0] info: - subject `C=US,ST=California,L=Pomona,O=California State Polytechnic University\, Pomona,OU=I(ampersand)IT Systems,CN=strategic.wiki.csupomona.edu', issuer `C=US,O=Thawte\, Inc.,CN=Thawte SSL CA', RSA key 2048 bits, signed using RSA-SHA1, activated `2010-09-10 00:00:00 UTC', expires `2011-09-10 23:59:59 UTC', SHA-1 fingerprint `57292bcd7541c56c7b664705f0192b43a927056c' - Certificate[1] info: - subject `C=US,O=Thawte\, Inc.,CN=Thawte SSL CA', issuer `C=US,O=thawte\, Inc.,OU=Certification Services Division,OU=(c) 2006 thawte\, Inc. - For authorized use only,CN=thawte Primary Root CA', RSA key 2048 bits, signed using RSA-SHA1, activated `2010-02-08 00:00:00 UTC', expires `2020-02-07 23:59:59 UTC', SHA-1 fingerprint `73e42686657aece354fbf685712361658f2f4357' - Certificate[2] info: - subject `C=US,O=thawte\, Inc.,OU=Certification Services Division,OU=(c) 2006 thawte\, Inc. - For authorized use only,CN=thawte Primary Root CA', issuer `C=ZA,ST=Western Cape,L=Cape Town,O=Thawte Consulting cc,OU=Certification Services Division,CN=Thawte Premium Server CA,email=premium-ser...@thawte.com', RSA key 2048 bits, signed using RSA-SHA1, activated `2006-11-17 00:00:00 UTC', expires `2020-12-30 23:59:59 UTC', SHA-1 fingerprint `1fa490d1d4957942cd23545f6e823d796ea2' - The hostname in the certificate matches 'strategic.wiki.csupomona.edu'. - Peer's certificate is trusted - As far as I can tell the web server is configured correctly, as web browsers and gnutls are happy with it. It's just openssl and applications that use it that seem to be failing for reasons I haven't determined. Thanks... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: generating keys from passwords
From: owner-openssl-us...@openssl.org On Behalf Of
muell...@mathematik.hu-berlin.de
Sent: Monday, 13 September, 2010 05:08
md5(admin [NO NEWLINE])= 21232f297a57a5a743894a0e4a801fc3
The next step is to understand the insertion of salt. I tried to
understand 'enc.c' and 'evp_key.c', for key derivation EVP_BytesToKey()
is called. I am not familiar with things like MDcontexts; BIOs etc,
man 3ssl EVP_MD_CTX_init # or wherever it is on your system
BIOs are used extensively in most of apps/*, but not relevant
to this key derivation which is entirely in EVP_BytesToKey().
so i don't understand it very well. But according to its documentation
it computes
D_0 = {}
D_i = hash(d_{i-1}||data||salt)
After that the key and iv are taken from D_1, D_2, ...
For DES it would be enough to generate D_1.
Yes. (Precisely because classic-DES is only 56-bit key
it is now practical to bruteforce, and hence insecure
for most use. I assume you will change later.)
data = 'admin'
As salt i use '', so
'Salted__' is passed
to EVP_BytesToKey - Anyway i cant reproduce
openssl enc -des -k 'admin' -P -S
salt=
key=752B559CFABA36F6
iv =9B6A524533353200
by hand. A Similar problem with
Note that the value for -S (and -K(uppercase) and -iv)
is hex, as is the output from -p/P (and dgst).
~/CSdev/hack $ od -xc t
00061646d696e00
a d m i n \0 \0 \0 \0 \0 \0 \0 \0
015
~/CSdev/hack $ openssl t md5 -binary |od -x
000 752b 559c faba 36f6 9b6a 5245 3335 3200
020
openssl enc -blowfish -k 'admin' -P -nosalt
key=21232F297A57A5A743894A0E4A801FC3 = md5(admin)
iv =7BED69E4F5F533BE != md5(md5(admin)||admin)..
can someone give me some hints..
~/CSdev/hack $ od -xc t0
00061646d696e00
a d m i n
005
~/CSdev/hack $ openssl t0 md5 -binary t1; od -x t1
000 2123 2f29 7a57 a5a7 4389 4a0e 4a80 1fc3
020
~/CSdev/hack $ cat t1 t0 | openssl md5 -binary | od -x
000 7bed 69e4 f5f5 33be e8a4 19b5 7be5 f229
020
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Intermediate root CA's -- lost and confused :(
On Mon, 13 Sep 2010, Tim Hudson wrote: Try gnutls without the TLS extensions processing occurring and you will see that the server is not sending back the certificate chain: Hmm, so the server isn't volunteering the chain, but if the client is smart enough to ask for it it will provide it :)? This fails. You need to correct your server configuration so that it correctly sends out the chain. I'm using bog-standard apache with mod_ssl, currently version 2.2.14. The instructions from Thawte were to use the SSLCACertificateFile directive in the config pointing to a file they provided containing two certs (the thawte Primary Root CA followed by the Thawte SSL CA). My server cert is signed by the Thawte SSL CA, and my openssl client has the Thawte Premium Server CA cert installed on it. This didn't work, as you point out it seems the server is not sending the chain. Per an off list discussion, I've changed my config and am now using the SSLCertificateChainFile directive instead (which seems to be the better way to do it). I also reversed the order of the certs in the file per a forum thread I found indicating they should be in order of verification. That's still not working, no chain from the server. Presumably somebody has one of these new Thawte certs installed under apache working correctly, could one of those somebodies possibly post what apache configuration directives they are using, and what certificates in what order are present in the intermediate ca file they are using? That would be greatly appreciated :). Thanks... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Intermediate root CA's -- lost and confused :(
Hi Paul, Can you test the SSLCertificateChainFile instructions from the following site : http://www.cam.ac.uk/cs/tlscerts/deploying-thawte.html? Your problem could come from the fact that your Apache SSLCertificateChainFile configuration is missing the Thawte Cross Root CA that links thawte Primary Root CA to Thawte Premium Server CA. -- Mounir IDRASSI IDRIX http://www.idrix.fr On 9/14/2010 3:32 AM, Paul B. Henson wrote: On Mon, 13 Sep 2010, Tim Hudson wrote: Try gnutls without the TLS extensions processing occurring and you will see that the server is not sending back the certificate chain: Hmm, so the server isn't volunteering the chain, but if the client is smart enough to ask for it it will provide it :)? This fails. You need to correct your server configuration so that it correctly sends out the chain. I'm using bog-standard apache with mod_ssl, currently version 2.2.14. The instructions from Thawte were to use the SSLCACertificateFile directive in the config pointing to a file they provided containing two certs (the thawte Primary Root CA followed by the Thawte SSL CA). My server cert is signed by the Thawte SSL CA, and my openssl client has the Thawte Premium Server CA cert installed on it. This didn't work, as you point out it seems the server is not sending the chain. Per an off list discussion, I've changed my config and am now using the SSLCertificateChainFile directive instead (which seems to be the better way to do it). I also reversed the order of the certs in the file per a forum thread I found indicating they should be in order of verification. That's still not working, no chain from the server. Presumably somebody has one of these new Thawte certs installed under apache working correctly, could one of those somebodies possibly post what apache configuration directives they are using, and what certificates in what order are present in the intermediate ca file they are using? That would be greatly appreciated :). Thanks... __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Intermediate root CA's -- lost and confused :(
On 9/13/10 2:58 PM, Paul B. Henson wrote: On Mon, 13 Sep 2010, Chris wrote: Be careful you are not checking the web server from a browser that has the intermediate certificate installed. I initially installed just the new cert on the web server, and the web browsers were generating cert security errors. I then went back and added the SSLCACertificateFile directive and the intermediate certs on the server; at that point the web browsers were happy. This leads me to believe the web server is correctly configured. SSLCACertificateFile is an adjunct to SSLCACertificatePath, and thus is for statements about what CAs your system will accept for client authentication. The directive that does only what you want is SSLCertificateChainFile, which is an ordered collection of PEM-encoded intermediate certifiers which may or may not include the root. (The root *may* be provided. X.509 tends to rely on roots being pre-shared. For various reasons, I believe that it is useful to send to the client, including the possibility of root certificate-update with the same keypair -- there's no reason not to share that information unless dissemination of the root's public key is by policy to be restricted for some reason.) -Kyle H smime.p7s Description: S/MIME Cryptographic Signature
Re: Intermediate root CA's -- lost and confused :( **SOLVED**
On Mon, 13 Sep 2010, Tim Hudson wrote: You need to correct your server configuration so that it correctly sends out the chain. Ok, I figured out what was wrong. I only had the SSLCertificateChainFile configured in the specific ssl virtual host, but not the default ssl virtual host. When I added the SSLCertificateChainFile to the default virtual host config as well as the specific ssl virtual host the server started sending the chain. That was a very frustrating and confusing ordeal 8-/. It's weird that the browsers started working when I added it just to the specific ssl virtual host config, that led me to believe the server was configured correctly when it wasn't. Thanks much to everybody that helped! -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Sign a file using OpenSSL and .cer files
From: owner-openssl-us...@openssl.org On Behalf Of ZK_ALI Sent: Monday, 13 September, 2010 08:49 openssl smime -sign ... -signer certificate certificate = abc.p7b Loading 'screen' into random state - done unable to load certificate 2140:error:0906D06C:PEM routines:PEM_read_bio:no start line:.\crypto\pem\pem_lib.c:663:Expecting: TRUSTED CERTIFICATE Can't read signer certificate file abc.p7b Can you please help me out for the same? Clearly abc.p7b does not contain a certificate in PEM format, as smime -sign needs. From the name, it could be a (PEM?) PKCS#7 that carries the cert or cert chain, possibly with other data. PKCS#7 was originally designed to transport data with certs and/or CRLs on the side, but is now used largely for the latter purpose not the former. If so, use openssl pkcs7 -in abc.p7b -print_certs abc.cer plus -inform DER if it's nonPEM and -text if you like to get (just) the cert(s) to a file, and if there is more than one cert, delete all but the correct one. Use that. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SHA-1 Hash Problem with i2d_Pubkey()
Hi David/Stefan, Thanks for the reply. The core of the problem was that after calling i2d_PUBKEY() issuer_pubkey was pointing to end of the buffer. Interesting part is why it was working [same pubkey data] all time in single test program and not my application. In single test program, issuer_pbukey was only malloc, so when I was dumping issuer_pubkey, it was nothing but common heap data which was same all the time. While is my application the heap data was changing all the time, bcoz of so many malloc() and free(), so issuer_pubkey was different in each run. Thanks again. Best Regards, Raj On Mon, Sep 13, 2010 at 3:22 PM, David Schwartz dav...@webmaster.comwrote: On 9/12/2010 11:38 PM, Raj Singh wrote: issuer_pubkey_len = i2d_PUBKEY(pubKey, NULL); issuer_pubkey = malloc(issuer_pubkey_len); i2d_PUBKEY(pubKey, issuer_pubkey); memory_dump(issuer_pubkey, issuer_pubkey, issuer_pubkey_len); The problem, is issuer_pubkey buffer is different each time, I run the my application using same code. Umm, you forgot to save the original issuer_pubkey. After the call to i2d_PUBKEY, issuer_pubkey points elsewhere. Try: issuer_pubkey_len = i2d_PUBKEY(pubKey, NULL); issuer_pubkey = malloc(issuer_pubkey_len); foo=issuer_pubkey; i2d_PUBKEY(pubKey, foo); memory_dump(issuer_pubkey, issuer_pubkey, issuer_pubkey_len); DS
Re: Intermediate root CA's -- lost and confused :( **SOLVED**
On 09/13/2010 10:12 PM, Paul B. Henson wrote: On Mon, 13 Sep 2010, Tim Hudson wrote: You need to correct your server configuration so that it correctly sends out the chain. Ok, I figured out what was wrong. I only had the SSLCertificateChainFile configured in the specific ssl virtual host, but not the default ssl virtual host. When I added the SSLCertificateChainFile to the default virtual host config as well as the specific ssl virtual host the server started sending the chain. That was a very frustrating and confusing ordeal 8-/. It's weird that the browsers started working when I added it just to the specific ssl virtual host config, that led me to believe the server was configured correctly when it wasn't. Thanks much to everybody that helped! Paul, Browsers tend to cache certificates they receive from servers, hence why when you visited the properly configured site, then all your other sites were working on that browser on that machine. IE does some wacky things in terms of verifying the certificate chain, so don't always trust it in terms of certificates. For verifying certificates, I love using OpenSSL's s_client utility. It is a god-send! (So long as you know what you should be seeing. -- openssl s_client -connect SITE:port -- (in some cases you can use the protocol for standard stuff,https, pops, etc.) and then read the certificate chain section and forget all the rest. (provided you know what you should see.) One key thing to remember is with OpenSSL, you don't necessarily have a default certificate store. (Same can be said for wget and others) I do believe OpenSSL packages on Debian and Red Hat based systems (maintainer releases) use the System SSL directory of 'etc/ssl/certs/' for root CAs, but remember it is best practice that the server present the whole chain (minus) the root CA as the client must have access to it. SSLCACertificateFile works on older versions of Apache 1.x and early versions of Apache 2.0.x the same way that SSLCertificateChainFile works on Apache 2.x nowadays. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
