I am using latest RabbitMq 3.5.6 with Erlang 18.1 on Ubuntu.
I want to secure communication with TLS. So I bought a wildcard certificate (AlphaSSL) which comes with an Intermediate cert chain.
(Removed Certs)
I am using the same certificate to secure Nginx and Apache2. The cert works there.
But in RabbitMq, I dont know how to get it working properly. At some stage of my testing, I had "Verfiy Ok" when testing with openssl -sclient... Then switched to browser, but management Interface doesn't even load: SSL_SEC_ERR in Chrome...
This is the config of the management section:
UPDATE: This config works. After doing apt-get install erlang-ssl --reinstall it suddenly works as expected. Make sure to use latest Erlang 18.1 Version from http://erlang-solutions.com/downloads/download-erlang-otp which contains some TLS related fixes
rabbitmq.config:
{rabbitmq_management,
{listener, [{port, 15672},
{ssl, true},
{ssl_opts, [{cacertfile, "/etc/rabbitmq/ssl/Intermediate_CA_Bundle.crt"},
{certfile, "/etc/rabbitmq/ssl/domain.crt"},
{keyfile, "/etc/rabbitmq/ssl/domain.key"},
{depth, 2},
{verify, verify_none},
{fail_if_no_peer_cert, false}]}]}
mablae
This config works. After doing apt-get install erlang-ssl --reinstall it suddenly works as expected. Make sure to use latest Erlang 18.1 Version from http://erlang-solutions.com/downloads/download-erlang-otp which contains some TLS related fixes
Related
I am hosting my website for free on heroku. So I have to enable SSL manually since their automated version is only available starting from the hobby dyno.
I've generated a certificate using:
sudo certbot certonly --manual
When I tried to add the certificate:
sudo heroku certs:add
/etc/letsencrypt/live/www.sitename.com/fullchain.pem
/etc/letsencrypt/live/www.sitename.com/privkey.pem
I got this error:
▸ You need to be running on either Hobby or Professional dynos to
be able to use SNI SSL.
I thought doing this manually was possible but apparently even manually I need the hobby version.
Just bypass Heroku's cert system altogether. I was able to secure my free level staging site by incorporating the cert file into the Procfile:
web: gunicorn mysite.wsgi --timeout 90 --certfile /certs/fullchain.pem --keyfile /certs/privkey.pem --keep-alive 5 --log-level debug --log-file -
The methodology should be similar to nginx or apache. Just work it into your Procfile.
rabbitmq supports certificate based authentication using the rabbitmq-auth-mechanism-ssl plugin (https://github.com/rabbitmq/rabbitmq-auth-mechanism-ssl/blob/rabbitmq_v3_6_9/README.md). I was able to get the password-less authentication working for the AMQP protocol using this plugin.
However, I could not get the same certificate based (password-less) authentication working for the rabbitmq-management plugin that uses HTTP (for web UI). From the documentation it is not clear if this is supported.
Does rabbitmq-management support the cert based authentication ? If yes, please share the relevant links.
Found this site - it looks legitimate, but I haven't tried it yet myself.
http://www.gettingcirrius.com/2013/01/securing-rabbitmq-management-console.html
Quoting from the link:
Edit the rabbitmq.config file in the /etc/rabbitmq director.
Add a configuration entry:
[{listener,
[{port, 15672},
{ssl, true},
{ssl_opts,
[{cacertfile, "/etc/rabbitmq/ssl/ca/cacert.pem"},
{certfile, "/etc/rabbitmq/ssl/server/{hostname}.cert.pem"},
{keyfile, "/etc/rabbitmq/ssl/server/{hostname}.key.pem"}]}
]}
]}
].
Restart RabbitMQ.
sudo service rabbitmq-server start
I read on various forums regarding POODLE vulnerability in SSLv3. It is recommended to disable SSLv3 and support TLS_FALLBACK_SCSV on servers.
How to enable support of TLS_FALLBACK_SCSV on apache2.2?
Upgrade to the latest version of openssl, which automatically supports TLS-FALLBACK-SCSV. Apache will use that.
From https://www.openssl.org/news/secadv_20141015.txt :
OpenSSL 1.0.1 users should upgrade to 1.0.1j.
OpenSSL 1.0.0 users should upgrade to 1.0.0o.
OpenSSL 0.9.8 users should upgrade to 0.9.8zc.
Debian and other Distributions are deploying backports of the TLS-FALLBACK-SCSV update on OpenSSL.
Restart your Apache after the update.
Check your server
SSL Labs will check whether you support TLS_FALLBACK_SCSV.
Notice how https://www.ssllabs.com/ssltest/analyze.html?d=google.com&s=74.125.239.96&hideResults=on notes "TLS_FALLBACK_SCSV supported"
It shouldn't be necessary to do both; TLS_FALLBACK_SCSV is a mechanism to prevent downgrade attacks, but if your server does not allow SSLv3 (or v2) connections it is not needed (as those downgraded connections would not work)
Edit (to incorporate feedback):
Technically TLS_FALLBACK_SCSV is still useful with SSL disabled, because it helps avoid the connection being downgraded to TLS < 1.2. But this is unnecessary to defend against POODLE, since the vulnerable SSLv3 is off.
The only reason TLS_FALLBACK_SCSV is helpful against POODLE is if you need to support SSLv3 clients (really old IE versions or something). Those clients will still be vulnerable to the attack, but modern clients which support that option would be safe against the downgrade attack.
Upgrade to the latest OpenSSL package that implements TLS_FALLBACK_SCSV. Then in your Apache configuration disable SSLv3 as well.
SSLProtocol all -SSLv2 -SSLv3
This answer on the 'askubuntu' stack site goes into a lot more detail and has answers for how to configure a bunch of different servers for this.
https://askubuntu.com/questions/537196/how-do-i-patch-workaround-sslv3-poodle-vulnerability-cve-2014-3566
As far as I understand it, it's not a configuration in Apache but a behavior of openssl.
OpenSSL has added support for TLS_FALLBACK_SCSV to allow applications
to block the ability for a MITM attacker to force a protocol
downgrade.
https://www.openssl.org/news/secadv_20141015.txt
On Debian, you can upgrade openssl without upgrading libssl, you really want libssl to be upgraded. Apache uses libssl.
I can confirm is not need change nothing on Apache (at least for Ubuntu 14.04) I have restarted Apache after the update of openssl and TLS_FALLBACK_SCSV is working.
Put the following line in your configuration file, or replace any existing line starting with SSLProtocol:
SSLProtocol All -SSLv2 -SSLv3
Then run: $ sudo apache2ctl configtest && sudo service apache2 restart
You can test running command $ openssl s_client -connect <host>:<port> -ssl3
TLS_EMPTY_RENEGOTIATION_INFO_SCSV is the magic-word.
For more details, refer to http://www.exploresecurity.com, this is what it says:
TLS_FALLBACK_SCSV is a fake cipher suite advertised in the Client
Hello, which starts the SSL/TLS handshake. SCSV stands for “Signaling
Cipher Suite Value”. The idea of using a cipher suite as a signal is
not new: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is a way clients can
advertise that they support secure renegotiation (addressing
CVE-2009-3555)
So, finally, for a Spring-boot project with embedded Apache Server, configuration would show up something like this:
server.ssl.enabled-protocols=TLSvx,TLSvx.y....
server.ssl.protocol=TLS
server.ssl.ciphers=TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,TLS_............TLS_EMPTY_RENAGOTIATION_INFO_SCSV
server.server-header="Willi Wonka!"
PS - To see all the the Spring-boot configurations / properties, plese visit this: https://docs.spring.io
I am running a secure site on apache and openssl 1.0.1.
This works fine in the browser, but when I curl the site, I am getting the following error
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)
From what I can find, this is some incompatibility between openssl 0.9.8 on the client, and 1.0.1 on the server.
Is there maybe some server-side configuration in mod_ssl to prevent this error, or would I be best to downgrade to 0.9.8, and if the latter, any advice for doing so on Ubuntu? For example, if I apt-get remove and apt-get install, do I need to reinstall / restart apache for the changes to take effect?
Thanks,
This is an old question, but since it is still unanswered:
This is a bug in OpenSSL 0.9.8, but can be fixed (or overridden) in Apache. See https://stackoverflow.com/a/8058839 for a fix. Note that the ServerName directive should be identical to the name used by the client (e.g., "localhost" will not work).
I am getting the below error while making ssl connection with self signed certificate.
"Peer certificate cannot be authenticated with known CA certificates"
It is working fine with CA signed certificate.
I am setting the below using curl_easy_setopt().
curl_easy_setopt(MyContext, CURLOPT_CAPATH, CA_CERTIFICATE_PATH)
curl_easy_setopt(MyContext, CURLOPT_SSL_VERIFYPEER,TRUE);
The curl version:
libcurl-7.19.7-26
Openssl version is:
0_9_8u
Please let me know how to solve this issue.
By default CURL will generally verify the SSL certificate to see if its valid and issued by an accepted CA. To do this, curl uses a bundled set of CA certificates.
If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option. Here's an example:
curl --noproxy -k \* -D - https://127.0.0.1:443/some-secure-endpoint
Security issue: This answer disables a security feature. Do not use this in production!
For php it is possible to switch off curl's verification of the certificate (see warning below) e.g. for curl_exec
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
http://php.net/manual/en/function.curl-setopt.php
(evaluate the security risk yourself, in my case it was on a partner company's server and the file required contained no secure information - just happened to be on a secure server)
We fixed a similar issue on CentOS 6 by updating curl to the latest version available in the standard repositories and installing the newest ca-certificates bundle:
yum update curl
yum install ca-certificates
libcurl performs peer SSL certificate verification by default. This is done
by using CA cert bundle that the SSL library can use to make sure the peer's
server certificate is valid.
If you communicate with HTTPS or FTPS servers using certificates that are
signed by CAs present in the bundle, you can be sure that the remote server
really is the one it claims to be.
Until 7.18.0, curl bundled a severely outdated ca bundle file that was
installed by default. These days, the curl archives include no ca certs at
all. You need to get them elsewhere. See below for example.
For more to know about Peer SSL Certificate Verification visit http://curl.haxx.se/docs/sslcerts.html
Though this error happened in the case of using git clone rather than with using curl, I've recently stumbled across an identical error message:
Peer certificate cannot be authenticated with known CA certificates
Similar to Arth's findings, something that worked for CentOS 6 (in order to successfully use HTTPS URLs with git clone for related GitLab repositories) involved updating the trusted certificates on the server (i.e., the server that is using HTTPS), using the following steps:
sudo yum install ca-certificates
sudo update-ca-trust enable
sudo cp /path/to/your_new_cert.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract
Perhaps the same certificate steps can be applied for the case of curl (or other similar scenarios) for users on CentOS in the future.
Security issue: This answer disables a security feature. Do not use this in production!
In 'C'
curl_easy_setopt(curl_handle, CURLOPT_SSL_VERIFYPEER, 0);
worked for me
As we checked and observed/ Found in Centos 8 .
Due to Proxy issue your packages not allowing you to get accessible to update or download any packages.
try to add sslverify=0 in file /etc/dnf/dnf.conf
Its worked for me.
Also make sure you must have proper internet acess on your server.