Im using nginx as a reverse proxy to serve an Express.js backend and a Vue.js frontend. The whole application runs in two Docker Compose images, one for development, and one for production. I’d like to be able to test the production image locally with HTTPS (especially because Vue’s PWA framework depends on HTTPS to properly register service workers).
The issue is that to configure a let’s encrypt certificate with certbot, I need to be running on a server associated with my domain through DNS. What is the correct way to set up a CI/CD workflow where I can test HTTPS locally and also push it to my production server? Do I have to buy a certificate from a different CA and update it manually?
I tried using certbot, but it will not work since I am not on the server that is associated with mine through DNS.
2
Answers
With certbot there is type of verification method DNS and HTTP
DNS method verify the record in DNS while HTTP check for 200 response from your Endpoint.
In CI/CD you can go with the HTTP method which checks for the Domain status
Refer repo for more : Auth script
Refer gist for DNS verification
Another option Manual one
During CI/CD or just want set cert in docker, i would suggest downloading/creating a cert first and use multiple time SSL for free
You locally create the cert first and re-use multiple times by injecting it during CI/CD process storing it in a variable or downloading from Bucket if you are using any cloud.
If the servers are independent – You don’t want to expose your production systems private key on a development machine – , you want different certificates and the question becomes "How do you use TLS on your development / testing infrastructure". This is a widely discussed question. E.g.:
https://web.dev/how-to-use-local-https/
https://security.stackexchange.com/questions/121163/how-do-i-run-proper-https-on-an-internal-network
If your Testing Infrastructure is accessible from the Internet for a Verification Method, you can setup certbot similar to a production machine, but you’d have to aquire a domain/subdomain for this.
Since the reverse-proxys config and certificates are likely not part of your software, you can treat it as infrastructure for your tests and just leave them in between tests. Treating infrastructure concerns independently of your application improves modularity and therefore maintainability.