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.
Related
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.
I have a VPS with Apache2.
I have installed SSL before in my websites, but always form freeSSL or ZeroSSL, they give me 3 files:
Private.key
ca_bundle.crt
certificate.crt
I replace them for the old ones and all is peachy (I configured it once and just replace the files on reactivation).
Now I have issued a year long SSL service from Comodo SSL, and they send me a mail with this information:
"Thank you for placing your order. We are pleased to announce that your PositiveSSL Certificate for * has been issued.
Attached to this email you should find a .zip file containing:
Root CA Certificate - AAACertificateServices.crt
Intermediate CA Certificate - USERTrustRSAAAACA.crt
Intermediate CA Certificate - SectigoRSADomainValidationSecureServerCA.crt
Your PositiveSSL Certificate - ***.crt
You can also find your PositiveSSL Certificate for ** in text format at the bottom of this email."
And I really have no Idea what to do... I tried Google but can't find any guide, they talk about CSR or other things and I just want to install this and forget about it for a year like I did before for 90 days...
Please help me, I need to have SSL running for my Magento 2 installation to work.
To use a certificate you need the certificate file itself (.crt) AND the key file (.key) ( Extensions may vary but, as you know, on linux it doesn't matter): if you're missing one of these, you're pretty much screwed.
To get a certificate, the following steps are necessary:
a key file needs to be generated
from the key file a CSR is generated
the CSR is signed by a CA (for you it's Comodo) and the result is the certificate file
The key file and the csr can be generate by you (who are requesting the new certificate) or (in this case) by Comodo during the procedure you followed. According to what you wrote, probably, during the procedure you've been asked to provide a key or let them generate one and you picked the 2nd option.
I've never used Comodo so I don't know how their interface works but IMHO you have 2 options: login with your account and look for an area where you can download the certificate and check for the possibility to download the key too OR contact them and ask for support to download the key file.
There is no way to use the certificate file without a key file.
I generated the certificate using an option of my webhosting service (Hostinger) to buy a comodo SSL certificate, as I said the email of Comodo didn't give me the key file BUT, after some hours the comodo ssl service started showing on my webhosting control center and going through some menus I reached a button called "download SSL", that downloaded a ZIP with the same files PLUS the key file. This was very random and nowhere stated, and I found it by coincidence but is solved. Thanks. The other option was to reach Comodo or Hostinger for help.
On Windows, the certificate viewer gives a decent UI for viewing an entire certificate path and exporting the base64 .cer files for each leaf, intermediate, and root. These exported files I've been cat'ing together to create a .pem chain that I need for my specific platform.
I've recently made a switch to Mac OS. I only have the leaf .cer file that I need to turn into a pem chain. Is there a way I could achieve this through the command line? Or another Mac tool?
An overview of how the certificate viewer works on Windows - When you have a leaf certificate, and double click to open it, you might see the entire chain if the CA chain is already trusted by the OS, or just the leaf certificate if the CA Chain is not trusted.
Windows looks at the Issuer Distinguished Name, and sees if the CA that issued that certificate is trusted. If it is trusted, it starts to form the certificate chain. It does the chain construction until the Issuer DN and the Subject DN are the same.
So when you have just the leaf certificate, you see the entire chain, but you technically don't have the whole chain in the certificate file. So what you were doing by downloading the each CA certificate and putting together would be the only option.
I have generate .p12 file from my server. But righ now we are developing IOS app which requires CA to implement it.
We are using Amazon EC load balancer server, so i have not idea where I can get CA, also is it possible that .p12 can generate CA?
A CA is a Certificate Authority. It is an organization that generates a public/private key pair for you. A PKCS#12 is a standard that explains how to store public/private key pairs in a file. Your .p12 file is such a file. It is a keystore that contains digital certificates (a public and a private key pair) as defined in PKCS#12.
If you have a .p12, there are two options:
Either your certificates are self-signed. In this case, you have created your own public and private key pair and you've stored it inside a .p12 file. As no CA is involved, there is no way to check if you created those certificates, or if somebody else impersonating you created those certificates.
Or you obtained that .p12 file from a CA. In this case, the CA signed your certificate and there is a certificate chain that eventually leads to the root certificate of your CA. A CA doesn't hand out such certificate to just anybody. A CA will first check that you are who you say you are. This way, whichever party gets confronted with your certificate (for instance because you used your private key to sign your code), knows that you are who you say you are, provided that your CA is a trusted party (there are CAs and then there are CAs).
This image shows how it works:
You are Bob, Apple is Alice, Trent is your CA. Apple wants you to work with a CA because Apple doesn't know you, but Apple knows CA. Once you make yourself known to the CA and once the CA trusts you, Apple will trust you.
See https://en.wikipedia.org/wiki/Alice_and_Bob to find out how the names in this image were chosen.
So the real question is: can you extract your public key from your .p12 file and show it to us so that we can see if your certificate is self-signed or if it's signed by a CA? Without that info, I don't think anyone can help you.
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.