The simple answer to this is that pretty much each application will handle it differently.
Also OpenSSL and GNUTLS (the most widely used certificate processing libraries used to handle signed certificates) behave differently in their treatment of certs which also complicates the issue. Also operating systems utilize different mechanisms to utilize "root CA"...
I had the same problem...
You have to include SSLProtocol all -SSLv2 -SSLv3 within every VirtualHost stanza in httpd.conf
The VirtualHost stanzas are generally towards the end of the httpd.conf file. So for example:
probably you are missing the openssl header files. depending on your distribution this package might have a different name, mostly it's something like openssl-dev or openssl-devel. after you installed the openssl header files, the compiler should be able to find openssl/sha.h.
In Ubuntu/Debian the package is called libssl-dev.
The thing you're missing is to include the certificate subject in the -subj flag. I prefer this to creating a config file because it's easier to integrate into a workflow and doesn't require cleaning up afterward.
One step key and csr generation:
openssl req -new -newkey rsa:4096 -nodes \
-keyout www.example.com.key -out www.example.com.csr \
Non Interactive Approach
For use in a non-interactive context (e.g. a chef recipe) you can use the following sequence.
sudo cp my.crt /usr/local/share/ca-certificates/
Tested and works on debian 5/6 & Ubuntu 14.04.
For more information, see man update-ca-certificates
This method is preferred over @Drav's method, since /...
From a web site, you can do:
openssl s_client -showcerts -verify 5 -connect stackexchange.com:443 < /dev/null
That will show the certificate chain and all the certificates the server presented.
Now, if I save those two certificates to files, I can use openssl verify:
$ openssl verify -show_chain -untrusted dc-sha2.crt se.crt
Give this a try:
lftp :~> set ftp:ssl-force true
lftp :~> connect ftp.domain.tld
lftp ftp.domain.tld:~> login <username>
NOTE: If the server is making use of self signed certificates you may need to add this set as well:
lftp :~> set ssl:verify-certificate no
Yes, I'm pretty sure you would need to reload Nginx in order for the renewed certificates to display the correct expiration date, but a simple cache-clearing and browse should allow you to view this.
Or if you prefer cli, you could always use the old trusty OpenSSL command:
echo | openssl s_client -connect your.domain.com:443 | openssl x509 -noout -dates
libssl1.0.2 and libssl1.0.0 are different packages, providing incompatible libraries; that’s why you can’t satisfy a libssl1.0.0 dependency using libssl1.0.2.
To satisfy your package’s requirements, I’d suggest adding the Debian 8 repositories to your configuration, since Debian 8 is still supported (so if necessary you’ll get security updates). To do so, ...
On receiving SIGHUP nginx will reload updated configuration, verify it while opening log files and reading SSL certificates, then gracefully shut down worker processes relying on previous configuration.
If it happens that nginx can't read some SSL certificates, I'll continue to run using older configuration. Otherwise put, it'll continue to function and ...
This is not an issue for OpenSSH since it doesn't make use of SSL.
excerpt - What is the difference between SSL vs SSH? Which is more secure?
They differ on the things which are around the tunnel. SSL
traditionally uses X.509 certificates for announcing server and client
public keys; SSH has its own format. Also, SSH comes with a set of
Some sites disable support for SSL 3.0 (possible because of many exploits/vulnerabilities), so it's possible to force specific SSL version by either -2/--sslv2 or -3/--sslv3.
Also -L is worth a try if requested page has moved to a different location.
In my case it was a curl bug (found in OpenSSL), so curl needed to be upgraded to the latest version (>7.40) ...
Your command would now expect a http request such as GET index.php for example. Use this instead:
if true | openssl s_client -connect www.google.com:443 2>/dev/null | \
openssl x509 -noout -checkend 0; then
echo "Certificate is not expired"
echo "Certificate is expired"
true: will just give no input followed by eof, so that openssl exits ...
Here is one-liner to verify a certificate chain:
openssl verify -verbose -x509_strict -CAfile ca.pem -CApath nosuchdir cert_chain.pem
This doesn't require to install CA anywhere.
See https://stackoverflow.com/questions/20409534/how-does-an-ssl-certificate-chain-bundle-work for details.
There is no documentation covering all of the conversions between the name of the cipher, and the name that curl is expecting as an argument.
Luckily, curl is open source, and the mapping is available in the source code.
For the benefit of future searchers, I reproduce it more neatly here:
SSL2 cipher suites
Debian Buster = TLSv1.3 supported
In Debian Buster (currently in testing), the TLSv1.3 is supported already.
The following information is dated to:
# date -I
# apache2 -v
Server version: Apache/2.4.38 (Debian)
Server built: 2019-01-31T20:54:05
Where to enable
There is a website that offers curl cipher requestion detection as a service:
However, it does not accept all ciphers - if one of the ciphers they accept is not on the list that your curl is sending, then you will not be able to get a response at all.
Make sure you do not have illegal characters in your virtual hosts' ServerName.
I ran into this issue while migrating "sub_domain.test.com" from Apache 2.2 to 2.4.
The underscore in "sub_domain" caused Apache 2.4 to respond with 400 (Bad Request) but no further hint in the error log.
Also have a look at https://stackoverflow.com/questions/2180465/can-...
That error message is appearing because the mail client is sending only a bare hostname ("PLLAMNAZIFE") rather than a fully-qualified hostname (e.g. "PLLAMNAZIFE.example.com") in the HELO/EHLO part of the SMTP transaction, and your Postfix server is configured to reject such mail.
Many mail client programs do not send correctly formatted, fully-qualified, ...
You need to install mod_ssl. Run:
sudo yum install mod_ssl
And it will place the default configuration file in /etc/httpd/conf.d/ssl.conf.
If for some reason you have mod_ssl installed, but the file is not there and yum says Nothing to do, try to reinstall with:
sudo yum reinstall mod_ssl
What you need is a chain certificate. You can create one like this:
cat /etc/ssl/server.pem /etc/ssl/cacert.pem > /etc/ssl/chain.pem
and then use the chain as the server certificate
ssl_cert = </etc/ssl/chain.pem
ssl_key = </etc/ssl/server.key
Now when you connect with openssl s_client, you should get no errors (provided everything else is set ...
June 2019 Update
It's here! Apache 2.4.37 (released 22-October-2018) adds support for OpenSSL 1.1.1 and TLSv1.3 . Make sure you use at least 2.4.39 though due to security issues.
March 2018 Update
TLS 1.3 draft is up to v26. There is general support in the main SSL libraries for varying versions of the Draft. It doesn't look like Chrome and Firefox have ...
No, it is not possible to generate the private.key file from the certificate.crt file. You will need to generate a new key and a new certificate, if the below does not apply to you.
You may ask your certificate provider if they're willing to re-generate your certificate, a few companies offer the possibility.
As already mentioned SUSE supports ca-certificates starting with openSUSE 13.1 / SLES 12.
The difference to debian/Ubuntu is the directory for your certififcates. The SLES man page to update-ca-certificates has these directories:
Directory of CA certificate trust anchors.