When using the rabbitmq_auth_backend_ldap, if we use ssl, is it necessary to mention SSL options to make sure we are talking to the right server, using options such as :
{ssl_options, [ {server_name_indication, "abc.com"},
{verify, verify_peer},
{depth, 5}]},
Note that I am not interested in doing client certificate authentication to the Ldap server, but only to verify whether I am actually talking to the right server, which cannot be ensured unless I verify the SN or similar from the certificate. Browsers kind of do that automatically, but how does RabbitMQ do this.
If the SSL certificate presented by the server is signed by a trusted root such as GoDaddy or such, should I still mention the certificates that I am trusting.
I verify the SN or similar from the certificate. Browsers kind of do
that automatically, but how does RabbitMQ do this.
Here is the answer to your question.
Every TLS-enabled tool and TLS implementation, including Erlang/OTP and RabbitMQ, has a way of marking a set of certificates as trusted. On Linux and other UNIX-like systems this is usually a directory administered by superusers. CA certificates in that directory will be considered trusted, and so are the certificates issued by them (such as those presented by clients). Locations of the trusted certificate directory will vary between distributions, operating systems and releases
More Info here
If you would like to have your own custom trust store. You can consider below stuff.
https://rabbitmq.docs.pivotal.io/37/rabbit-web-docs/ssl.html#keys-and-certs
https://github.com/rabbitmq/rabbitmq-trust-store
So without the below configurations, at a minimum, I feel that the SSL security is not complete for a LDAP setup.
In case of LDAP, the connection is made from the RMQ server(via erlang client) to the LDAP server, so at that point of time the SSL certificates are presented by the LDAP server.
RMQ server(client) -> LDAP server(server)
and Unless the following options are specified, the certificate is not validated.
{servers, ["abc.com"]},
{timeout, 10000},
{use_ssl, true},
{ssl_options, [ {cacertfile, "/etc/ssl/certs/ca-certificates.crt"},
{server_name_indication, "abc.com"},
{verify, verify_peer},
{depth, 5}]},
{port, 636}
verify: verify_peer
indicates that we prefer the certificate chain to be verified
will be verified that the certificate chain terminates from one of the trusted certificates mentioned in cacertfile.
cacertfile
will point to the certificates to trust.
It can be pointed to a file which contains a list of trusted
certificates in ---Begin Certificate--- ---End Certificate-- format
If the LDAP servers certificates are signed by trusted root
certifcates we can point this variable to
/etc/ssl/certs/ca-certificates.crt.
If the server certificates are self signed then point to a file
containing appropriate certificates.
server_name_indication:abc.com
this enforces that this is just not some server we are talking to but
only abc.com
will verify that the server certificates SN has abc.com.
depth:
this indicates the number of certificates in the certificate chain
that we will traverse before it needs to terminate into one of the
trusted certificates we have.
keep this a bigger number than the no of certs in your servers cert chain
This is without any client cert authentication between the LDAP server and the RMQ server.
Related
I read that ejabberd recommends to use STARTTLS negotiation for secure connection between communicating entities. When I install ejabberd, by default it comes with a TLS certificate.
Then, why do I need to buy a certificate to install? what is the purpose of buying a new certificate from Certificate Authoririty since we have a default certificate?
When I deploy ejabberd on the machine, how the default certificate will be used for my domain? How the default certificate will be verified by client?
You can use ejabberd with SSL / STARTTLS with the provided TLS certificate. However, that certificate is only a self-signed certificate. It means that:
You will still be able to encrypt the traffic between the client and the server.
You client will not be able to check that the server is the domain it pretends to be. To be able to know that the certificate can be trusted the client need to refer to a trust authority in some way.
In the second case, it means that if an intermediate network device (i.e Wifi access point) tries to impersonate your server, it can present any self-signed certificate to the user, pretending to be your domain.
So, you can definitely use self-signed certificate to encrypt traffic, but to protect your users against man-in-the-middle type of attacks, you need to find a way to let the client now it can trust the certificate.
This can be done either by buying a certificate from a trusted authority (that will certify your certificate domain) or by making the client support a list of well defined certificates. This is called certificates pinning, however it requires to build the list of acceptable certificates into your client, which may not be possible.
It may be fine in your case, so buying a certificate is not mandatory.
However, not use the default ejabberd self-signed certificate, even if you plan using a self-signed certificate. The certificate provided with ejabberd will not match your own domain. You should at least generate your own self signed certificate that match your actual XMPP domain: How to create a self-signed certificate with openssl?
The client will verify whether the certificate is issued for the domain name of the Jabber ID (JID), the part behind the '#'. (There are other options, but they are incompatible with the policies enforced by the browser vendors against CAs and therefore not practical.)
Unless you already have a business relationship to a certificate authority (CA), I would recommend anyone to use Let's Encrypt and stay away from self-signed certificates.
Some instructions to automate this and be nice to the Let's Encrypt servers can be found here and the linked wiki pages.
Summary (assuming you are running Ubuntu 16.04 LTS, want to run it on the domain example.org and only use the certificate for ejabberd):
Create /usr/local/sbin/auto-renew-letsencrypt with the following content:
#!/bin/bash
# Renew all Let's Encrypt certificates which are due for renewal
t=`mktemp`
# Try to be quiet unless an error is returned
letsencrypt renew > $t || cat $t
# Hooks are not yet supported by `letsencrypt` shipping with Ubuntu 16.04 LTE
# Crudely emulate --renew-hook; breaks if diagnostic messages change
if grep -q "The following certs have been renewed" $t; then
cat /etc/letsencrypt/live/example.org/{privkey,fullchain}.pem > /etc/ejabberd/ejabberd.pem
service ejabberd reload
fi
rm $t
Run the following commands to create and activate the certificate and the automatic renewal
apt install letsencrypt
letsencrypt certonly --standalone --domain example.org
cat /etc/letsencrypt/live/example.org/{privkey,fullchain}.pem > /etc/ejabberd/ejabberd.pem
chown ejabberd:ejabberd /etc/ejabberd/ejabberd.pem
chmod 640 /etc/ejabberd/ejabberd.pem
chmod 755 /usr/local/sbin/auto-renew-letsencrypt
echo $(($RANDOM % 60)) $((RANDOM % 6)) "* * * root /usr/local/sbin/auto-renew-letsencrypt" > /etc/cron.d/auto-renew-letsencrypt
During SSL handshake, the browser downloads any intermediate certificate from the host web server using the URL provided if needed. I believe browser comes with the pre-installed certificates from public CAs having only the public key of the root certificate.
1) When calling a https url using a standalone java program [https://xyz.com ..which is using Verisign certificate], i do not need to add that Certificate to any truststore since its root public is already available in jdk's cacerts truststore file. Is this correct statement?
2) When i run the same program from application server, it requires to add all the intermediate certificate to server truststore individually. Why this works in different way.
If the trust chain for the servers certificate is: root-intermediate#1-intermediate#2-server and the client (browser) has root as trusted CA in its CA store, it needs a way to verify the servers certificate by checking the complete chain up to the root. And because the client usually has no knowledge of the intermediate CAs the server needs to provide them.
Sometimes it seems to work w/o providing these intermediate CAs. First, the browsers usually cache the intermediate CAs they got and thus if intermediate#2 is the same as already seen by another server the verification will succeed, but only for the clients who visited the other server before :(
Another way is to provide a URL inside a certificate, where the issuer certificate can be downloaded, e.g. server could provide a link to the certificate for intermediate#2, intermediate#2 could provide a link to intermediate#1. In this case the client could download the missing certificates. But, this features is not universally adopted, e.g. some browsers might provide it but SSL libraries outside of the browsers usually don't.
I know that for MTLS , both parties , Client and server exchange certificates. These certificates should be signed by a CA that both parties can trust in order to validate the certificate.
My question is , does MTLS also means in addition to verifying the certificate (if CA is trusted, leaf certificate is trusted) , either side (Server or client) can also do some additional checks like Hostname check or Whether the client connecting to the server is in the list of approved trusted entities?
Can anyone point me to the mTLS specification and what are the overheads in mTLS?
Besides what EJP has said about "MTLS" term, the TLS 1.2 specification doesn't have strict requirements regarding what information is to be checked and in which way.
It's up to the receiving party to decide if the presented certificate is to be trusted or not. This means that for example it's ok for the server to accept only certificates issued by the CA that belongs to the company that owns the server. This is how client-bank access systems often work - they accept only certificates issued by the bank and the common name of such certificate must correspond to the username provided in a web form.
Both parties are free to check any information in the certificate including direct comparison of public key hash (thus only particular keypairs will work no matter what is contained in other certificate properties).
The most up todate RFC regarding this subject is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/
this is an extension to OAuth 2.0
The purpose of this document is to define a mechanism how TLS certificate is used in a context of replacing Client ID and Secret (aka, Client Credentials)
The standard establishes two mechanisms how a TLS Certificate is used as a client credential, and the associated token flows, and attributes.
The general summary of this is:
(a) Authorization Server: checks the certificate either according to PKI (signed by a valid root) The RFC does not define the options, but they are pretty self-explanatory and depend on the use case. But it can be (1) certificate is signed by a trusted root and, is not revoked, (2) individually recognize each certificate based on some logic.
(b) Resource server checks the token and client certificate (client credential, or CC), and used in the underlying TLS session. Please note that there are no validation checks concerning the certificate or its origin at TLS layer, all checks are performed at an Application layer. The resource server should, therefore, configure the TLS stack in a way that it does not verify whether the certificate presented by the client during the handshake is signed by a trusted CA certificate.
This mechanism becomes particularly interesting in some GDPR context, as it makes it impossible to share tokens between client and the server.
Overall a great feature for privacy, and improved security.
mTLS can be implemented by issuing all parties a CA certificate and adding these to all communicating parties, which is a sort of an access control list. Whoever has their CA certificate in your app's trust store is able to connect.
The trust system however is the same as with TLS in the case of a https connection - you can issue several certificates from the same CA and add the root CA certificate to the trust store of your app. It will trust all certificates issued from the same root. This is arguably easier to set up as you only have to add the app's own certificate and the CA root. However, if you want to revoke a certificate, it becomes a little more complicated.
I wrote a guide to generate certificates here:
https://thoughts-about-code.blogspot.com/2021/12/creating-a-ca-for-mtls-with-openssl.html
First:
Both server and client certificates have to be built with the same CA certificate and key
see : https://github.com/ysimonx/mtls-ssl-generator/blob/main/generate_certificates.sh
So you have to store the CA certificate on both sides :
On the server side : you can allow (this is optional) a client that provides client cert built with the same CA than its own certificate. (see rejectUnauthorized: true)
https: {
requestCert: true,
rejectUnauthorized: true,
key: fs.readFileSync("./certificates/server/serverKey.pem"),
cert: fs.readFileSync("./certificates/server/serverCrt.pem") ,
ca: [fs.readFileSync("./certificates/ca/caCrt.pem")]
}
(exemple for a fastify nodejs https self-signed certificate server)
On the client side : you can allow (this is optional too) a server that provides (or not) the same CA certificate as the client knows
curl -k --cert ./certificates/client/clientCrt.pem --key ./certificates/client/clientKey.pem https://localhost:3000/
(parameter -k : do not verify the server certificate based upon a CA authority)
or
curl --cacert ./certificates/ca/caCrt.pem --cert ./certificates/client/clientCrt.pem --key ./certificates/client/clientKey.pem https://localhost:3000/
if you want the client to match the correct CA cert used by the server
There is no 'MTLS Specification', for the very good reason that there is no such thing as 'MTLS'. You just made it up. The TLS specification, including mutual authentication, is to be found in RFC 2246 as amended.
The TLS APIs should make the peer certificate chain available to the application, so it can do any additional checking it likes.
'MTLS', insofar as it exists at all, refers to an Internet Draft for multiplexed TLS.
According to https://wiki.jasig.org/display/CASUM/X.509+Certificates,
After the Server sends the certificate that identifies itself, it then can then send a list of names of Certificate Authorities from which it is willing to accept certificates.
I am wondering how to determine what this list is, and how to modify it.
The reason I am asking is that I am getting an infinite redirect between my server and my client after successful validation (i.e., the ticket stage), and I think it has to do with the CAS server not recognizing the CAS client's certificate (the client's certificate is self-signed).
If you want to see what this list is, you can use OpenSSL:
echo "" | openssl s_client -connect your.server:port
This will show various messages regarding the handshake, including the certificates and the list of CAs in the CertificateRequest message.
Ultimately, it's determined by the active X509TrustManager's getAcceptedIssuers() method. By default, this will be the list of Subject DNs of all your trust anchors (that is, the Subject DNs of all the certificates in your trust store).
Your client certificate will have to be verified by the server. This is normally done during the handshake by the trust manager, which (unless tweaked) will build a chain to a known CA (or at least known cert if it's the user cert itself) in the trust store.
Adding your self-signed certificate to your trust store should be sufficient. It doesn't have to be the cacerts file bundled with the JVM, you could make a copy of it and use the trust store settings of Apache Tomcat's connector to set it up.
I'm trying to configure Apache Tomcat to use SSL connection with client authentication (two way authentication). My certificates are CA signed.
If I put CA certificate, together with client certificates, in tomcat truststore everything is OK. If I don't put CA cert in tomcat truststore, Tomcat won't trust to clients.
Do I need CA certificate in tomcat truststore?
If I put CA certificate in truststre then Tomcat will trust to every client that have certificate signed by the same CA.
Yes, you need the CA in the truststore. If you are unwilling to put the CA in the truststore, you should not use the CA.
Regarding your last paragraph, you could also examine the Distinguished Name of the client certificates for further authorization.
You are confusing trust, or authorization, with authentication. The only purpose of SSL certificates is to prove that the peer is who he says he is, i.e. establish his identity. You need to decide whether or not you trust that CA's procedures for verifying identity prior to signing CSRs, and if so put its certificate into the truststore.
Whether you want that identity to access parts of your system is a completely different question which you must solve in a different way, via a database of roles granted to identities. This is something that LDAP is particularly good at, but you can also use a DBMS or even an XML file in Tomcat. Have a look at Tomcat Realms for how to do this.
What you mustn't do is attempt to use the truststore as that database. That's not what it's for, and not the purpose for which it or PKI was designed. Which is why you're having problems trying to use it that way.