i have a Question about the certificate files and how to get a site to run on SSL.
Apache is running and SSL is built in. i am past the SSLSessionCache warning and here i am - every time the same problem - i get a mail with some files and i do not know which file is what.
I have a .key, .pem and a .p7b file and i have the VirtualHost config - how do i know which file is what?
SSLCertificateFile ?
SSLCertificateKeyFile <-- .key (i think)
SSLCertificateChainFile ?
and do i need to convert a file with openssl?
This Server is an internal Server and the certificate was issued in our company.
the certificate was issued in our company.
Any reason to not ask whoever issued the certificate the meaning of each file?
Apache requires the key and the certificate to be PEM-encoded. You can use this tool or OpenSSL to convert the . p7b to PEM.
It's hard to know what's inside the .pem and .key file without looking at the content. You can try to use the following OpenSSL commands to check which one does not fail:
# if it works, it's a CSR
openssl req -in file.pem -noout -text
# if it works, it's a certificate
openssl x509 -in file.pem -noout -text
# if it works, it's a private key
openssl rsa -in file.pem -noout -text
The chain file it's easier to spot, because it will contain several PEM-encoded certificates listed one after the other.
Depending on the Apache version, you may or may not need the SSLCertificateChainFile directive. Newer versions require you to bundle the chain and the server certificate in a single file and pass it to SSLCertificateFile. Check your Apache version and compare it with the online documentation.
Assuming it's an old version:
SSLCertificateFile points to the server certificate file
SSLCertificateChainFile points to the intermediate certificate (if it's self-signed, you don't have them)
SSLCertificateKeyFile points to the key
If it's a newer version, ignore SSLCertificateChainFile and concatenate the server plus the chain (if any) in a single file you supply to SSLCertificateFile.
Related
I am with little knowledge of certificates.
Need add certificate for jetty (v.9.4.11) which is a part of application.
Try with self-signed - all OK. But now, need do it with organization official certificate.
Administrator gives me 2 files - .cer and .p7b. Documentation of application said that enough command like:
keytool -import -trustcacerts -alias mydomain -file mydomain.crt -keystore keystore.jks
I will try this command with .cer instead .crt. Keystore was created, configured jetty-http.xml and started application. Try open - and error SSL_ERROR_NO_CIPHER_OVERLAP.
Check with openssl connect to my address with -tsl1/1_1/1_2 - nothing, connection ok, but but nothing in keystore.
Check with keytool content of keystore - 1 entry, trustedCertEntry and no key (not private/not public)
Is it real to configure only with this 2 files - .cer/.p7b or i need something else?
Usually when setting up SSL Certificates, you will more often than not have 2 or 3 files.
The base working format for certificates is a certificate / key pair.
For example, you could have a certificate for example.com with it's associated key.
example.com.cer
example.com.key
If the certificates were created using a provider, you will most likely also need the Root Certificate Authority. In our infra for instance, our ROOT CA's are in the .pem or .cer format. Here is a config for one of my webservers, using the entrust.crt as the root ca chain file :
SSLCertificateFile /etc/apache2/ssl/apache.crt
SSLCertificateKeyFile /etc/apache2/ssl/apache.key
SSLCertificateChainFile /etc/apache2/ssl/entrust.crt
In your case, you have a .p7b file. P7B files often have more than a single entry, they can contain both the certificate and the ROOT CA's chains. You can open the p7b in a windows machine, then find the certificates and right-click > Export. Export your files in Base64 and set them on your server.
The problem was that beginner .csr-file was incorrect.
-Recreated it
get .cer
run in cmd: certutil -repairstore my "serial" for generate key
export to .pfx
-connect apllication to .pfx
I got valid https certificate from Let's Encrypt, but have trust issues giving it to vert.x version 3.6.2
I tested the cert with apache, it's ok, however if I try to reach the https vert.x server instance with wget I get:
$ wget https://www.myhost.mydomain/json/read/all-languages
--2019-01-22 10:30:56-- https://www.myhost.mydomain/json/read/all-languages
Resolving www.myhost.mydomain (www.myhost.mydomain)... 88.14.34.156
Connecting to www.myhost.mydomain >(www.myhost.mydomain)|88.14.34.156|:443... connected.
ERROR: cannot verify www.myhost.mydomain's certificate, issued by >‘CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US’:
Unable to locally verify the issuer's authority.
To connect to www.myhost.mydomain insecurely, use `--no-check->certificate'.
Hostname and ip is forged.
my working apache config snippet:
SSLCertificateFile /etc/certs/myhost.mydomain/cert.pem
SSLCertificateKeyFile /etc/certs/myhost.mydomain/privkey.pem
SSLCertificateChainFile /etc/certs/myhost.mydomain/chain.pem
vert.x code:
val httpsOptions = HttpServerOptions()
.setPort(443)
.setSsl(true)
.setPemTrustOptions(PemTrustOptions()
.addCertPath("/etc/certs/myhost.mydomain/chain.pem"))
.setPemKeyCertOptions(PemKeyCertOptions()
.addKeyPath("/etc/certs/myhost.mydomain/privkey.pem")
.addCertPath("/etc/certs/myhost.mydomain/cert.pem")
)
vertx.createHttpServer(httpsOptions).requestHandler(router).listen()
I set vert.x logging to debug, but no error message appears.
What am I missing?
I found the solution here: https://community.letsencrypt.org/t/android-doesnt-trust-the-certificate/16498/2
I changed the cert.pem to fullchain.pem in the setPemKeyCertOptions settings, and it works.
Thank you for your effort.
The issue is in the certificate chain file chain.pem. It seems that it does not contain the full certificate chain. If you view the file it probably contains only one intermediate LE authority cert inside, i.e., Let's Encrypt Authority X3. It works with Apache because the SSLCertificateChainFile is actually deprecated and it is not being used at all.
Vert.x on the other side does use the chain.pem file. It returns only the intermediate cert and wget complains because of that. To fix the issue create a fullchain.pem file composed of both the chain.pem and the cert.pem files, e.g.,
cat cert.pem chain.pem > fullchain.pem
Then use the fullchain.pem with the PemTrustOptions configuration.
You don't need to put the LE root certificate in the fullchain.pem file, because it should already be present on both client and server side. Here's an excerpt from the TLS Protocol RFC about it.
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.
I'd like to generate a CRT/KEY couple SSL files with Let's Encrypt (with manual challenge).
I'm trying something like this :
certbot certonly --manual -d mydomain.com
But I only get these files in my /etc/letsencrypt/live/mydomain.com folder :
cert.pem
chain.pem
fullchain.pem
privkey.pem
Did I missed something?
I'm the author of Greenlock, a certbot-compatible Let's Encrypt v2 client, so I've had to learn the ins and outs of all these things as well.
Hopefully this helps:
KEY
privkey.pem is the "key" file
Sometimes it is improperly named as cert.key or example.com.key.
CRT
fullchain.pem is your "crt" file.
Sometimes it is improperly named as example.com.crt.
CRT/KEY Bundle
bundle.pem would be made like so: cat fullchain.pem privkey.pem > bundle.pem
HAProxy is the only server that I know of that uses bundle.pem.
cert.pem
cert.pem contains ONLY your certificate, which can only be used by itself if the browser already has the certificate which signed it, which may work in testing (which makes it seem like it may be the right file), but will actually fail for many of your users in production with a security error of untrusted certificate.
However, you don't generally use the cert.pem by itself. It's almost always coupled with chain.pem as fullchain.pem.
chain.pem
chain.pem is the intermediary signed authority, signed by the root authority - which is what all browsers are guaranteed to have in their pre-built cache.
Checking certs
You can inspect the cert only like so:
openssl x509 -in cert.pem -text -noout
There's a list of useful commands here:
https://www.sslshopper.com/article-most-common-openssl-commands.html
I have two files:
privkey.pem that starts with -----BEGIN ENCRYPTED PRIVATE KEY-----
cert.pem that starts with -----BEGIN CERTIFICATE-----
Now I should install them, but I never did this before and all related information I found (1, 2, 3) say, that I need three files:
primary.crt
private.key
intermediate.crt
The file endings are different, but from what I found my .pom files are ok, too (only the content matters and I can rename the ending).
But what files do I have now? The primary and private? And do I miss some file? Or is it possible with only the two I have?
Start with this:
SSLEngine on
SSLCertificateFile /path/to/cert.crt
SSLCertificateKeyFile /path/to/privkey.crt
This should bring the site up on SSL. While this may work with some browsers, you'd require intermediate certificates for your certificate to chain up to the Root CA to ensure your site works in all browsers.
To obtain the intermediate certificates for your site, go to What's My Chain Cert? and enter you site name. This will indicate that you are missing intermediate certificates, as expected. Use the last form field on the page to generate the intermediate certs.
Use the downloaded cert chain in the SSLCertificateChainFile directive in your Apache webserver config like this:
SSLCertificateChainFile /path/to/intermediate.crt
Once done, I suggest checking your site using an online scanner such as SSL Labs server test to ensure your certificates are properly configured and that your configuration does not expose any vulnerabilities or SSL weaknesses.
I purchased a Godaddy Certificate, I correctly installed it on my Mac Server, so now I see 2 entry within Keychain Application:
Go Daddy Secure Certification Authority
mydomain
mydomain (private key)
Then I added the certificate (mydomain.com) to a VirtualHost of httpd.conf file, so:
<VirtualHost *:443>
DocumentRoot "/Library/ApacheTomcat/apache-tomcat-6.0.33/webapps/MyServerAppName"
ServerName mydomain.com
ErrorLog "/private/var/log/apache2/mydomain.com-error_log"
CustomLog "/private/var/log/apache2/mydomain.com-access_log" common
SSLCertificateFile /etc/apache2/mydomain.cer
JkMountCopy On
JkMount /* ajp13
</VirtualHost>
Then, I guess, I also need the private key file, otherwise Apache fails to handle the certificate.
How to do this? I can save the certificates from Apple Keychain into .pem and .cer file.
In the Keychain, export your private key and certificate in PKCS#12 format (.p12 file, Personal Information Exchange). You should be able to do this using by expanding your private key entry (in Keychain Access), right-clicking on its certificate and using Export. It will probably ask you for a password to protect this p12 file.
Then, in the Terminal, extract the private key using OpenSSL:
umask 0077
openssl pkcs12 -in filename.p12 -nocerts -nodes -out filename-key.pem
umask 0022
Note that you should protect this file, since the private key will not be password protected (so that it can be used by Apache Httpd).
Similarly, for the certificate (although it seems you may already have it in PEM format, so you might not need this step):
openssl pkcs12 -in filename.p12 -clcerts -nokeys -out filename-cert.pem
Then, set the SSLCertificateFile (cert) and SSLCertificateKeyFile (private key) options to point to these files in your Apache Httpd configuration.
I had the same problem and I used these commands to export the private key
umask 0077
openssl pkcs12 -in filename.p12 -nocerts -nodes -out filename-key.pem
umask 0022
and these to export the certificate
openssl pkcs12 -in filename.p12 -clcerts -nokeys -out filename-cert.pem