Apache not checking crl for revoked certificates [closed] - apache

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I'm having an issue I can't really identify the cause of.
I set-up for testing purposes a local CA and a Webserver in a VirtualBox under Ubuntu.
I'm willing to try Client Certificate-Authentification.
I got it so far, that I can't access the webserver without having a valid certificate in my browser.
The problem is, that after revoking the Certificate, I still access the server.
In my default-ssl.conf (which is loaded) I have set :
SSLCARevocationFile to /etc/ssl/CA/crl/crl.pem
"crl.pem" was created using "openssl ca -gencrl /etc/ssl/CA/crl/crl.pem"
openssl crl -in /etc/ssl/CA/crl/crl.pem -text generates the following :
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
Last Update: May 29 13:10:55 2014 GMT
Next Update: Jun 28 13:10:55 2014 GMT
CRL extensions:
X509v3 CRL Number:
4106
Revoked Certificates:
Serial Number: 01
Revocation Date: May 29 10:35:53 2014 GMT
Serial Number: 02
Revocation Date: May 29 00:32:33 2014 GMT
Signature Algorithm: sha256WithRSAEncryption
4a:95:31:27:df:2b:d3:5f:91:86:32:18:7e:04:1f:88:99:22:
2b:d6:03:8d:c6:1d:81:ca:06:a0:c3:c2:cf:fe:cb:8a:ec:f9:
7f:bb:37:4c:69:70:1e:43:0c:8e:97:89:f7:32:f8:bf:9c:3b:
fc:b2:25:55:98:a1:fe:7f:fb:ab:79:13:67:d6:75:02:c6:74:
03:34:bc:f3:df:61:d5:0f:e6:1e:24:8b:e7:b0:17:1b:c4:2f:
16:56:44:8d:e4:92:1f:48:51:23:a5:1d:54:26:a4:58:6b:4d:
07:40:bb:48:7f:c1:61:00:55:20:d2:a1:56:f9:38:fa:f9:84:
de:2a:a5:2a:69:82:d7:8b:35:24:5b:4d:ee:c0:33:7c:b6:d6:
83:e2:f8:79:76:f9:04:55:80:45:8c:b1:9d:5b:8d:29:65:f9:
6d:de:d3:d2:53:6e:f0:d2:44:c9:3e:60:ca:67:0f:2b:f9:27:
0d:36:4b:90:d5:fe:7b:23:74:6b:94:e3:93:ea:4f:90:2b:db:
c8:96:29:4b:cc:42:f6:31:27:e6:a2:ce:a3:c8:fa:47:74:bd:
32:51:71:f3:66:fb:2d:76:0f:ca:64:23:55:eb:f8:5e:bc:0d:
eb:f9:e4:7a:7f:72:be:fd:1a:a7:76:32:5e:0f:21:b9:c7:2a:
89:ac:53:26
-----BEGIN X509 CRL-----
MIIByTCBsgIBATANBgkqhkiG9w0BAQsFADBFMQswCQYDVQQGEwJBVTETMBEGA1UE
CAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRk
Fw0xNDA1MjkxMzEwNTVaFw0xNDA2MjgxMzEwNTVaMCgwEgIBARcNMTQwNTI5MTAz
NTUzWjASAgECFw0xNDA1MjkwMDMyMzNaoA8wDTALBgNVHRQEBAICEAowDQYJKoZI
hvcNAQELBQADggEBAEqVMSffK9NfkYYyGH4EH4iZIivWA43GHYHKBqDDws/+y4rs
+X+7N0xpcB5DDI6Xifcy+L+cO/yyJVWYof5/+6t5E2fWdQLGdAM0vPPfYdUP5h4k
i+ewFxvELxZWRI3kkh9IUSOlHVQmpFhrTQdAu0h/wWEAVSDSoVb5OPr5hN4qpSpp
gteLNSRbTe7AM3y21oPi+Hl2+QRVgEWMsZ1bjSll+W3e09JTbvDSRMk+YMpnDyv5
Jw02S5DV/nsjdGuU45PqT5Ar28iWKUvMQvYxJ+aizqPI+kd0vTJRcfNm+y12D8pk
I1Xr+F68Dev55Hp/cr79Gqd2Ml4PIbnHKomsUyY=
-----END X509 CRL-----
I tried both certificates with the serial 01 and 02 and I'm able to login with both of them.
Does anybody has an idea what the problem may be ?
Thank you !

Try putting the following Directive in your conf files (i.e. default-ssl.conf)
SSLCARevocationCheck chain
then stop and start your apache2 service and see the result.
Supawat P.

I would try to gracefully reload server configuration after revoking the certificates and generating new CRL because it seems to be a necessary step.

Related

New SSL certificate verification errors - what's the root cause?

My application uses the Close API (https://developer.close.com/) to store user data. Our testing environment is now getting SSL errors when trying to write to it:
Faraday::SSLError (SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (certificate has expired))
What could the cause be? My first assumption reading the error message is that the Close certificates might have expired. But that seems unlikely - the service is generally well-maintained, and we are not having any issues in production.
The next thing I considered was that perhaps the certificate store on our server is out of date. That would not surprise me much, because the server is running Ubuntu 14, and other people are experiencing problems there. But we have multiple machines with the same configuration, and only one of them is giving us trouble. Is it possible this is the root cause?
To reproduce:
$ openssl s_client -CApath /dev/null -showcerts -connect api.close.com:443 -servername api.close.com
CONNECTED(00000003)
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
The problem turned out to be the recent deprecation of the DST root certificate. An old root certificate (DST) was deprecated on Sep 30, and the modern version (ISRG) is now expected.
The testing server still had the DST and ISRG certificates installed, whereas all the other machines only had ISRG. I assume that something about this particular API was looking preferentially for the DST certificate and ignoring ISRG unless it was the only one.
To solve: Remove DST cert from /usr/share/ca-certificates/mozilla and leave ISRG one there - try the openssl command above, now it works.

CN field is missing in SSL certificate from subject

I have SSL certificate, and I want to know the domain name associated with the certificate, for that I am using openssl to get the text of the .crt file.
The sample output is as follows:
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 87778 (22)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=IN, ST=Maharastra, L=Mumbai, O=Tests Pvt Ltd, OU=test/emailAddress=all#test.com
Validity
Not Before: Jan 2 02:09:10 2014 GMT
Not After : Dec 31 02:09:10 2023 GMT
Subject: C=IN, ST=Maharastra, L=Mumbai, O=Tests Pvt Ltd, OU=test/emailAddress=all#test.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
As we can see there is not CN field in the above certificate, let me know if the certificate is wrong, or we can expect certificate files without CN.
With HTTPS a server certificate is expected to contain the name of the server and this name should match the expected name, otherwise the TLS handshake will fail. The name is specified today using the Subject Alternative Names (SAN) extension and before that was given using the CN of the subject. But the CN is considered obsolete for years and browsers like Chrome will not consider it anymore, i.e. make the SAN mandatory.
The certificate in your case contains neither CN nor SAN and thus will not be usable for HTTPS. There are other use cases of SSL/TLS apart from HTTPS though where this certificate might be acceptable. But it is unclear what specific use case you have.

SSL showing 128bit encryption for 2048 bit private key [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 years ago.
Improve this question
I have created a privatekey.key during SSL creation for CSR certificate creation for getting SSL certificate. I have purchased the certificate and configured SSL in my Apache server, after that when I restart the server it stops working, for make it working I have used the following command as follows:
C:\Apache24\bin> openssl rsa -in privatekey.key -out privatekey.key
After that when I restarted my Apache it is working fine. But now it is showing me that 128 bit encryption, but I had created the key for 2048 bit encryption. How can I make it 2048 bit encryption?
Please check the following image:
You have got to be aware that SSL/TLS uses hybrid encryption: During the handshake it uses asymmetric encrytpion like RSA to exchange a key for some symmetric encryption-algorithm like AES that is then used to encrypt the traffic. The reason is that asymmetric encrpytion is rather slow compared to symmetric algos, so you use those on the bulk data to get better performance and reduce server-load.
Also take care that asymmetric algorithms require significantly longer keys for the same "strength". While 256-bit AES might sound less secure than 4096-bit RSA they might actually be quite similar from the offered protection.
So while you are using 2048-bit RSA for the key-exchange, 128-bit-AES is used to encrypt the payload.
P.S.: the cipher used during the session is negotiated between client and server from a list of ciphers each support during the SSL-handshake.

SSL certificate intermediate CA [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
So I have a private key and an SSL Certificate. Is there a way to find out which CA signed it?
Thanks!
The name of the CA that issued your certificate is in the Issuer Distinguished Name (DN).
You can see all of this with OpenSSL using:
openssl x509 -text -noout -in the-certificate.pem
The name of the certificate's Issuer DN should match the name of the CA cert Subject DN.
You can check with most browsers. Make sure you've navigated to your site so that the certificate has made a handshake with your browser. With Firefox, go to Tools -> Options and on the dialogue that pops up, you'll see an icon for "Advanced." Click that, then you'll see another tab below for "Encryption." Click that tab as well.
Now you can see a button that says "View Certificates." Clicking that will bring up a dialogue window showing the certificates that your system recognizes. The "servers" tab is where you will find the certificate for your site, and it will show you which CA signed it.

SSL Certificate [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I am building a buy-system and i was told to set up an SSL certificate on my web-server to work with bank operations.
I am new to this and i don't exactly understand the difference between OpenSSL (which is free and opensourced) and SSL certificates, that are needed to be bought (thawte.com).
I guess OpenSSL is smth like tool to create a keys (ive alredy done this for firstdata.com), but if i buy ssl certificate on thawte.com and install it ill have my web-site running over https?
Can i use free openSSL to work with banks? Or i have to buy one?
The biggest difference between a self-issued (with OpenSSL) certificate and one you buy from thawte (or somewhere else) is that of trust. If you want your users to use access your ssl enabled website without being prompted for "do you trust the certificate from this issuer?" you need to buy a certificate from a trusted certification authority, such as thawte or one of the others.
Your website will run over https with any old x.509 certificate so if you only have a few people accessing your ssl site you may convince them to trust your self-issued certificate and save the money for the certificate.
OpenSSL is a tool and a library that can be used to generate certificate requests (CSR), self-signed certificates and issue certificates from a CA (if it's a CA you control of course).
There are a number of pre-trusted certification authorities embedded in most browsers. They issue certificates by signing the certificate they give you (coming from your certificate request). In turn, the certificates they issue can be verified by your users' browsers against their (issuing) CA certificate because it's shipped with them by default.
You can generate your own CA and issue certificates yourself, but the problem is that your CA certificate won't be trusted by default in most browsers, so it's worthless unless you make your users import it explicitly (which is fine for corporate CAs for example, but is impractical in general). A self-signed certificate is a special case of this: it's the root CA certificate you generate or a one-off certificate for a given machine; either way, you'd have to import it explicitly.
Some pre-trusted CAs will let you use OpenSSL to generate the certificate request as part of their procedure, but they may also offer other procedures relying on other tools. Which tool you or they use doesn't really matter. What you want is a certificate issued by a CA your remote party will trust.
You can sign up for free and generate free SSL certificate for your web site, at least for the first year, on StartSSL. Their site shows Weekend Maintenance now, but it will be available later. I was able to get free SSL certificate from them. This certificate is signed by Startcom certification authority which is trusted, according to their site.