We are using Puppet to configure multiple clusters running Apache HTTPD using the Apache module from Puppetlabs.
All certificates are stored in a git repository Puppet has already access to (e.g. puppet://files-host/path/to/certs/${fqdn}.crt).
Right now we have to explicit specify the intermediate CA certificate (ssl_chain variable in the apache class) for each used certificate.
Is it possible to let Puppet automatically find out the correct intermediate CA certificate? In a "real" scripting language I would iterate over all *.pem files and compare the subject with the issuer of the certificate. But how could that work in Puppet?
We do not want to embed the intermediate CA certificate into all certificates.
I've got a solution for my problem. It's not the optimal way, but it seems to be the only one in case of a Puppet managed infrastructure.
All intermediate CA certificates are located in a single directory in the git repository and Puppet will put the whole content of the folder to the managed hosts (set the "recursive" and "purge" attributes of the file resource to true).
Each certificate and key file is also deployed using file resources. The file resource for the certificate file will notify an exec resource executing a shell script which symlinks the right CA certificate to a static file path (i.e. /etc/ssl/private/my-domain.pem -> /etc/ssl/ca/some-ca.pem. So there are three files for each FQDN (fqdn.crt, fqdn.key and fqdn.pem).
Related
I have already successfully installed certbot and have a working digital certificate. I was wondering how do I go about adding domain names to the certificate or do I need to recreate the certificate again?
I don't want to mess up the existing certificate. I haven't tried running this code yet I want to verify the process before I continue. I tried searching this and Google and my results were kind of confusing.
sudo certbot –apache -d mydomain.xyz -d mydomain2.xyz -d www.mydomain.xyz
SSL certificates cannot be modified once issued. They can be replaced with new certificates.
If you run the identical or modified certbot command, your existing certificate will not be modified or deleted. The certbot command will create a new certificate and store the certificate under a different name. Certbot stores certificates and additional files under the directory tree /etc/letsencrypt. You can archive/backup those files. Look at the archive and live folders.
Typically, your webserver will use symbolic links to point to the Let's Encrypt folder instead of copying the certificate to an Apache/Nginx folder.
From SSL2BUY I have the text for a certificate starting with "-----BEGIN CERTIFICATE-----" down to "-----END CERTIFICATE-----". There is no download option just an email option (but that person isn't available) how do I convert the encrypted text between the 'begin' and 'end' statements to an actual certificate?
There are also 4 sections within this page; Servers, PKCS7, Root and Intermediate. How do these all interact?
SSL has been a bane of my life for a long time and I need to conquer this once and for all -_-.
Any assistance will be much appreciated.
I would like to inform you that Servers Certificate and PKCS7 Certificate are different formats of certificate.
PKCS7 format certificate is used in java based server like Tomcat and if you are not using Tomcat you can disregard it.
If you are using a server like IIS, cPanel, Apache etc then you will need to install "Server Certificate". You need to paste the certificate in notepad and save it with .cer extension.
If you are using a windows based server(IIS) then you will need only 1 file to install there which is "server certificate". On Windows based servers, root & intermediate certificates came preinstalled so you can skip that, they are not needed to install again.
If you are servers like Apache, cPanel, Nginx, Plesk, etc then you need to install the main domain certificate and CABundle(combination of the Root and Intermediate certificate).
Please Note:
For all leading CA's (Comodo, Digicert and GlobalSign) all the Root and Intermediate certificates are different. Please suggest your product name so I am able to assist in that particular product which Root and Intermediate certificate has to be used.
Please let me know the server type you are using such as Apache, IIS, cPanel, etc.
"""You also need CA certificates bundle file for SSL support. Download cacert.pem from the cURL site, rename it to curl-ca-bundle.crt, and place in the directory where you make installer, or in any directory listed in PATH environment variable."""
I did the same and stored it in "c:\python27"
but it gives me the following error.
value "C:\Python27\caret.pem" is not valid for "ssl.ca_certs"
No valid trusted SSL CA file set . See 'bzr help ssl.ca_certs" for more information on setting trusted certificates.
I got past this error by skipping the rename step.
I downloaded cacert.pem to "C:\Python27\" (no name change) and these errors went away.
On Debian, using GitLab, I ran into issues with my self-signed certificate.
Reading through the code after a lot of searching on the Internet (I guess, it's the last resort, FOSS is helpful), I found the following lines in gitlab-shell/lib/gitlab_net.rb which left me... perplexed.
if config.http_settings['self_signed_cert']
http.verify_mode = OpenSSL::SSL::VERIFY_NONE
end
Most Stack Overflow responses about the diverse issues I've had until now have led me to believe that VERIFY_NONE, as you'd expect, doesn't verify anything. VERIFY_PEER seems, based on my reading, to be the correct setting for self-signed.
As I read it, it feels like taking steps to secure my connection using a certificate, and then just deciding to not use it? Is it a bug, or am I misreading the source?
gitlab-shell (on the GitLab server) has to communicate to the GitLab instance through an HTTPS or SSH URL API.
If it is a self-signed certificate, it doesn't want any error/warning when trying to access those GitLab URLs, hence the SSL::VERIFY_NONE.
But, that same certificate is also used by clients (outside of the GitLab server), using those same GitLab HTTPS URLs from their browser.
For them, the self-signed certificate is useful, provided they install it in their browser keystore.
For those transactions (clients to GitLab), the certificate will be "verified".
The OP Kheldar point's out in Mislav's post:
OpenSSL expects to find each certificate in a file named by the certificate subject’s hashed name, plus a number extension that starts with 0.
That means you can’t just drop My_Awesome_CA_Cert.pem in the directory and expect it to be picked up automatically.
However, OpenSSL ships with a utility called c_rehash which you can invoke on a directory to have all certificates indexed with appropriately named symlinks.
(See for instance OpenSSL Verify location)
cd /some/where/certs
c_rehash .
Is it possible to use pip with a requirements file to install from a Mercurial repository which needs to be accessed using --insecure in order to work.
The repository is accessed via SSL, and due to pip ignoring Server Name Indication (SNI), a valid SSL certificate is not being honoured (it uses the main certificate for the IP address). --insecure gets round this issue
ie:
hg clone https://username#domain.org/username/app_name --insecure
So where you can usually do something like this:
pip install -e hg+https://username#domain.org/username/app_name#egg=app_name
or have the following in a pip requirements file:
hg+https://username#domain.org/username/app_name#egg=app_name
Neither of these work due to the SSL SNI issue.
Does anyone have any good suggestions?
Why don't you try to use [hostfingerprints] in your ~/.hgrc?
For example:
[hostfingerprints]
example.com = 38:76:52:7c:87:26:9a:8f:4a:f8:d3:de:08:45:3b:ea:d6:4b:ee:cc
To obtain the self-signed certificate, follow the steps suggested in https://www.mercurial-scm.org/wiki/CACertificates
The root CA certificate for a server can for example be retrieved with
Firefox. Browse to https://example.com/repo and verify that this is the
repository you trust, click the lock symbol in the lower right corner,
View Certificate, Details, select the certificate at the top of the
Certificate Hierarchy, Export, "X.509 Certificate (PEM)" and save
somewhere for example as server.pem. With other browsers on Windows
you have to view the certificate at the top of the Certification Path
and "Copy to File" as "Base-64 encoded X.509 (.CER)". Several such
files can be concatenated into one cacerts file.