I just want to say that this is not normally something I do, but I have been tasked with it recently...
I have followed the heroku documentation for setting up SSL closely, but I am still encountering a problem.
I have added my cert to heroku using the following command:
heroku certs:add path_to_crt path_to_key
This part seems to work. I receive a message saying:
Adding SSL Endpoint to my_app ... done
I have also setup a CNAME for my hosting service to point to the endpoint associated with the cert command above. However, when I browse to the site I still receive a SSL error. It says my certificate isn't trusted and points to the *.heroku.com license, not the one I have just uploaded.
I have noticed that when I execute the following command:
heroku ssl
I receive the following:
my_domain_name has no certificate
My assumption is that there should be a certificate associated with this domain at this point.
Any ideas?
Edit: It appears that I did not wait long enough for the certificate stuff to trickle through the internets... however, my question regarding the "heroku ssl" command still puzzles me.
The Heroku ssl command is for legacy certificates:
$ heroku ssl -h
Usage: heroku ssl
list legacy certificates for an app
The command you need is heroku certs which will output the relevant certificate info for that project.
Related
I use cert-manager to generate TLS certificates for my application on Kubernetes with Let's Encrypt.
It is running and I can see "ca.crt", "tls.crt" and "tsl.key" inside the container of my application (in /etc/letsencrypt/).
But "ca.crt" is empty, and the application complains about it (Error: Unable to load CA certificates. Check cafile "/etc/letsencrypt/ca.crt"). The two other files look like normal certificates.
What does that mean?
With cert-manager you have to use the nginx-ingress controller which will work as expose point.
ingress nginx controller will create one load balancer and you can setup your application tls certificate there.
There is nothing regarding certificate inside the pod of cert-manager.
so setup nginx ingress with cert-manager that will help to manage the tls certificate. that certificate will be stored in kubernetes secret.
Please follow this guide for more details:
https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-with-cert-manager-on-digitalocean-kubernetes
I noticed this:
$ kubectl describe certificate iot-mysmartliving -n mqtt
...
Status:
Conditions:
...
Message: Certificate issuance in progress. Temporary certificate issued.
and a related line in the docs:
https://docs.cert-manager.io/en/latest/tasks/issuing-certificates/index.html?highlight=gce#temporary-certificates-whilst-issuing
They explain that the two existing certificates are generated for some compatibility, but they are not valid until the issuer has done its work.
So that suggests that the issuer is not properly set up.
Edit: yes it was. The DNS challenge was failing, the debug line that helped was
kubectl describe challenge --all-namespaces=true
More generally,
kubectl describe clusterissuer,certificate,order,challenge --all-namespaces=true
According to the documentation, cafile is for something else (trusted root certificates), and it would probably be more correct to use capath /etc/ssl/certs on most systems.
You can follow this guide if you have Windows Operating System:
tls.
Article is about how to enable Mosquitto and clients to use the TLS protocol.
Establishing a secure TLS connection to the Mosquitto broker requires key and certificate files. Creating all these files with the correct settings is not the easiest thing, but is rewarded with a secure way to communicate with the MQTT broker.
If you want to use TLS certificates you've generated using the Let's Encrypt service.
You need to be aware that current versions of mosquitto never update listener settings when running, so when you regenerate the server certificates you will need to completely restart the broker.
If you use DigitalOcean Kubernetes try to follow this instruction: ca-ninx, you can use Cert-Manager and ingress nginx controller, they will work like certbot.
Another solution is to create the certificate locally on your machine and then upload it to kubernetes secret and use secret on ingress.
I purchased my SSL certificate from GoDaddy.
I made the common name www.mywebsite.com.
In my DNS settings I have the website forwarding from the naked domain to the www.mywebsite.com.
I removed any settings inside Heroku regarding the SSL certificate from the GUI.
Then I went through the instructions here.
To recap, I generated my server.key by first creating the crs files and sending those to GoDaddy.
I purchased the $20/mo endpoint.
GoDaddy gives me a downloadable ZIP for my certificates, one with one certificate, and one with 3 certificates inside of it.
I run the following command to install the bundled version first with the following failing message that follows:
heroku certs:add server.crt server.key --type endpoint
No certificate given is a domain name certificate.
The reason I even tried to use the bundle is that my SSL doesn't work in firefox, and intermediary cert is not being included. After looking around for an answer on this, I couldn't find one.
So to get my website back up and running in the short term, I decided to just do what I did before, and upload the single cert. That works, but not really.
Now I get this message when I run the cUrl test:
* error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error
Also, my website is down. :(
How do I fix this?
The answer in my case seems to be that purchasing an SSL cert is not necessary on Heroku. When you purchase a paid hosting package they provide SSL certificates by default without having to buy their SSL add-on endpoint.
There are likely other use-cases for using a paid SSL cert, but in my case I didn't have to do that.
If this answer helped you please upvote this question as some people seem to think it's a question worth down voting.
I'm having issues trying to renew a recently expired certificate issued with let's encrypt.
I tried launching the following commands:
./letsencrypt-auto renew
and
sudo ./letsencrypt-auto certonly --text --agree-tos --email dev#intuizone.com --renew-by-default --webroot --webroot-path /home/lovegistics -d lovegistics.it
which was the code I used to issue the certificate. Both of the command said that the certificate was succesfully renewed/issued, but it still gives me unsecure connection.
Since I was on WHM, I took a look on the manage SSL page, and it says that the certificate has actually expired yesterday.
The output for the second command:
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/lovegistics.it/fullchain.pem. Your cert will
expire on 2016-11-20. To obtain a new or tweaked version of this
certificate in the future, simply run letsencrypt-auto again. To
non-interactively renew *all* of your certificates, run
"letsencrypt-auto renew"
I'm sorry, but I lost the output for the first one. Strangely, when I try to relaunch the renew command, it says that the certificates are not due for renewal yet.
How can I renew this certificate?
Thank you all in advance for your help.
EDIT: I restarted the web server (Apache) after each of these commands
Finally I managed to solve my problem. The certificates were created successfully, but since I was on a CPanel server, they must be installed. In the following link there is an explanation directly from the cpanel team with a pearl code to copy-paste and execute when you have generated the certificate.
cpanel forum explanation
Happy coding!
Check certificate:
certbot certificates
Renew command:
certbot renew --force-renewal --cert-name api2.example.in --deploy-hook "sudo service nginx restart"
have to go through a minimum number of measures to [instal Let's Encrypt SSL certificates][1].
First, by accessing active domains such as http:/yourdomain.com:2083 or http:/yourdomain.com/cpanel, go to cPanel.
When you proceed to the protection tab, the Let's Encrypt SSL icon is visible to you.
Click on the + Issue button as soon as you proceed to the Issuing a New Certificate arena.
You've got to click on your domain name then. Email the server when you're done with it. Then pick, and confirm, HTTP-01.
Click the problem button once you finish it.
I have a heroku app hosted at www.example.com.
I have a certificate issued for that address (www.example.com). I've installed the certificate successfully according to the heroku docs.
However, I how have a problem:
when I visit www.example.com, I get an invalid CN error (says that it is issued for *.herokuapp.com)
when I visit example.herokuapp.com, I also get an invalid CN error (this time the cert CN is for www.example.com)
So the certificates are pretty much flipped. This is still pretty fresh (<1 hour) - could waiting solve the problem?
Also: This part of the heroku docs shows an endpoint in the form example.herokussl.com
$ heroku certs:info
Fetching SSL Endpoint example-2121.herokussl.com info for example... done
And I'm getting the standard example.herokuapp.com endpoint, so I did not have to change the DNS settings after installing the certificate. Could that be some clue?
If you have already configured your domain DNS for non-SSL, standard http:// access, keep in mind that you need to update it again for SSL. From your Heroku account, go to your app settings, Domain section. You will see something like:
In this example, the example.com's DNS should be updated to point to example-ssl.herokussl.com (and not example-standard.herokuapp.com).
Turns out this was a DNS caching issue on my machine. Since this was Linux, changing browsers did not work (also for some reason restarting the dns deamon).
Anyway, it's fine now.
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 .