Hot answers tagged


On many systems (Ubuntu, Suse, Debian, ...) run the following command to enable Apache's SSL mod: sudo a2enmod ssl a2enmod man page


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: ... ... <VirtualHost> DocumentRoot /var/www/directory ServerName ... ...


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 -out \ -subj ...


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/ sudo update-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 < /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 se.crt: OK Chain: depth=0:...


Give this a try: $ lftp 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 | 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, ...


tl;dr - one liner bash magic to dump all certs in the chain openssl s_client -showcerts -verify 5 -connect < /dev/null | awk '/BEGIN/,/END/{ if(/BEGIN/){a++}; out="cert"a".crt"; print >out}' && for cert in *.crt; do newname=$(openssl x509 -noout -subject -in $cert | sed -n 's/^.*CN=\(.*\)$/\1/; s/[ ,.*]/_/g; s/__/_/g; s/^_/...


On CentOS 7 installing the package "mod_ssl" and restarting the apache server worked for me: yum install mod_ssl systemctl restart httpd


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 protocols ...


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 2>/dev/null | \ openssl x509 -noout -checkend 0; then echo "Certificate is not expired" else echo "Certificate is expired" fi 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 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 <argument> <name> ...


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 2019-02-24 Apache2 version: # apache2 -v Server version: Apache/2.4.38 (Debian) Server built: 2019-01-31T20:54:05 Where to enable Globally in: /etc/apache2/mods-enabled/ssl.conf Locally in: ...


httpd24 solution: yum install mod24_ssl


There is a website that offers curl cipher requestion detection as a service: curl 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 "" 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


That error message is appearing because the mail client is sending only a bare hostname ("PLLAMNAZIFE") rather than a fully-qualified hostname (e.g. "") 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


On Debian and Ubuntu you have to copy the certificate.pem to /usr/local/share/ca-certificates/certificate.crt and then run dpkg-reconfigure ca-certificates. /etc/ssl/certs is managed by that command.


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: FILES /usr/share/pki/trust/anchors Directory of CA certificate trust anchors. /usr/share/pki/trust/blacklist ...

Only top voted, non community-wiki answers of a minimum length are eligible