I have two MQTT server environments: PROD and PILOT. These environments each have their own separate certificate authorities. I have one client which can use either CA certificate to connect to each environment. Is it possible to combine these two CA files into a single file so that the CA file need not be changed in the client when I change the environment?
Sample client:
mosquitto_sub -h server.com --cafile /path/to/ca.file
Please note that the CA files contains intermediate CA as well. Please refer another post where I mention this.
From the man page:
--cafile
Define the path to a file containing PEM encoded CA certificates that are trusted. Used to enable SSL communication.
Note the certificates in plural form :-)
Your file should only contain trust-anchors - the Root CA certificates. The other certificates in the chain should be sent by the server. You should consider reconfiguring your server so that the whole chain is sent in line with the TLS protocol (read certificate_list here).
While it often works, placing intermediate certificates in the trust-anchors store doesn't help matters. If you were to renew the intermediate (which happens more often than the root) then you will need to replace the intermediate in all your clients. Might not be an issue in your case, but in the real-world that is a major headache. Also, depending on the libraries used and how the developers wrote the client, it may not check revocation of the intermediate if it is used as a trust-anchor.
The file pointed to by --cafile should be a concatenation of PEM encoded Root CA certificates.
Related
I'm trying to fix an issue related to an expired ca certificate.
I replaced a the certificate located at /etc/puppetlabs/puppet/ssl/ca/ca_crt.pem (with these instructions).
Then restarted puppet-server, but agents still see an expired certificate.
I noticed there is also a value localcacert which points to a slightly different path etc/puppetlabs/puppet/ssl/certs/ca.pem.
I see this little snippet on Puppet documentation:
Where each client stores the CA certificate.
Default: $certdir/ca.pem
I'm confused by this. The description makes it sound like a folder where clients store certificates, yet the value is a single pem file.
Can anyone clarify the difference between these two ca pem files?
If I update one can I just overwrite the other with my new pem?
Can anyone clarify the difference between these two ca pem files?
The cacert setting is relevant only to the master. It specifies the location of the certificate with which the master's hosted CA will sign communications.
The localcacert setting specifies the location of the client's copy of the CA certificate (containing the public key, not the private one). This is what machines will use to verify certificates signed by the CA.
In both cases, you should not read too much into the word "location". These settings designate certificate files, not directories.
Letsencrypt is fantastic because it lets users generate valid (not self-signed) SSL certificates for free. I'm using bip as an IRC proxy. Bip can use an SSL certificate for encryption, but the documentation is a bit fuzzy on this.
I know how to generate certificates with letsencrypt. I guess I must concatenate some of the letsencrypt generated files, among cert.pem, chain.pem, fullchain.pemandprivkey.pem` to get a valid bip certificate. But which ones?
If you're asking how to configure bip to use the Let's Encrypt certificate so that clients can connect to it via SSL, the documentation provides the following:
client_side_ssl (default: false)
When true, clients will need to connect to BIP using SSL. You'll also need to
generate a SSL cert/key pair in <bipdir>/bip.pem (usually ~/.bip/bip.pem or
/var/lib/bip/bip.pem) or <client_side_ssl_pem> if defined.
client_side_ssl_pem (default: <bipdir>/bip.pem)
Set this to the full path of the cert/key pair bip should use to accept clients
SSL connections
So from that I gather you will need to cat privkey.pem cert.pem > bip.pem and enable client_side_ssl and point client_side_ssl_pem to bip.pem if it's not in one of the specified locations.
I don't believe you'll need to add the CA chain as Let's Encrypt is a trusted CA and the clients should be able to reconstruct the chain themselves. If that's not the case, you can add chain.pem to bip.pem as well.
I also found a handy guide that might be of use here: https://flexion.org/posts/2014-04-bip-irc-proxy/
I'm setting up 2-way SSL communication between services on different hosts. Let's say I have my own CA called A. A is trusted by all of my services through a centralized jks. Now let's say I have certificate B signed by A. When services send the certificate should they be sending the entire chain B - A, or just B? I believe both tend to work with most implementations.
I tried to find canonical information about this online, but I'm coming up with nothing.
Thanks for the help
As per tls - Validating an SSL certificate chain according to RFC 5280: Am I understanding this correctly? - Information Security Stack Exchange:
the server should send the exact chain that is to be used; the server
is explicitly allowed to omit the root CA, but that's all.
Reference (RFC 5246 - TLS v1.2, sec. 7.4.2. - Server Certificate):
certificate_list
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following certificate
MUST directly certify the one preceding it. Because certificate
validation requires that root keys be distributed independently, the
self-signed certificate that specifies the root certificate
authority MAY be omitted from the chain, under the assumption that
the remote end must already possess it in order to validate it in
any case.
The idea behind the trusted root CA is that it is trusted. Would you expect the browser to trust anything sent by the server just because it includes a root CA? No!
Therefore the root CA must be already at the client and must be trusted there. It should not be included in the certificate chain by the server, but if you do it anyway browsers will simply ignore it.
Cowboy: https://github.com/extend/cowboy
In the ssl example, three files are needed in ssl folder, they are
cowboy-ca.crt, server.crt and server.key.
I am applying for a free ssl in startssl, and found there are only
server.crt and server.key generated.
What is cowboy-ca.crt used for?
My question is that 'is cowboy-ca.crt needed for me'?
Thanks in advance
SSL is built on the principle of a chain of trust. The reason why you are using StartSSL (or any other certificate provider) is that you are asking them to sign your certificate and create such a chain of trust for you. If clients trust StartSSL they will trust your server's certificate.
Sometimes, clients do not have all the previous elements of the chain. This is the case in Cowboy example where clients probably do not know the sample root certificate, cowboy-ca.crt. For this reason, during SSL handshake, servers can send part of this chain. This does not create trust, unless clients aldready trusted the root or the prefix of the chain.
In your case, the chain actually contains three elements with an intermediate certificate. This is what you should use here as clients trust the root only and might not know the intermediate certificate. If you are using a free certificate from StartSSL, it is sub.class1.server.ca.pem. You can download it here.
I have a question about certificate files with Apache + OpenSSL.
I have generated the following basic certificate files from the server:
/usr/share/ssl/csr/mydomain.csr.pem
/usr/share/ssl/private/mydomain.key.pem
I have sent the mydomain.csr.pem to the CA authority after purchasing Comodo's Positive SSL at
http://www.namecheap.com/ssl-certificates/comodo.aspx
It's approved and got three *.crt files, which are:
AddTrustExternalCARoot.crt
PositiveSSLCA2.crt
mydomain_com.crt
Based on the Apache tutor at
http://www.apache.com/resources/how-to-setup-an-ssl-certificate-on-apache/
looks like I only need to use mydomain_com.crt and put it in
/usr/share/ssl/certs/mydomain_com.crt
My question is, what do I have to do with these two files?
AddTrustExternalCARoot.crt
PositiveSSLCA2.crt
Looks like it's not necessary, then what are these files given to us? If they are used, then when and how?
You may need to specify the PositiveSSLCA2.crt in the Apache configuration. If the HTTP client trusts Comodo, they should already have the root certificate.
I found instructions on this page for configuring the intermediate certificate. Basically, you would specify the PositiveSSLCA2.crt in your Apache configuraiton as the SSLCertificateChainFile. Your client may trust the root CA, but it probably does not know about the intermediate certificate, therefore could not establish trust without it.
The root CA is probably just for your information, but it might be needed if you ever use an HTTP client that requires you to specify it directly, for trust purposes.