I'm trying to get an SSL certificate for a web api on a specific port.
I have test.ruttie.dev redirecting to ip:8001 (a SRV record).
I want to get an SSL certificate for this domain.
How can I do this?
If the usual ports aren't blocked, you can get a certificate using the regular processes and configure your web API with the acquired certificate.
3 Likes
When using the regular process I get the following:
certbot certonly -d test.ruttie.dev --server "https://dv.acme-v02.api.pki.goog/directory" --standalone
Saving debug log to C:\Certbot\log\letsencrypt.log
Requesting a certificate for test.ruttie.dev
Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
Domain: test.ruttie.dev
Type: incorrectResponse
Detail: DNS look-up of test.ruttie.dev returned no results.
Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 80. Ensure that the listed domains point to this machine and that it can accept inbound connections from the internet.
Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile C:\Certbot\log\letsencrypt.log or re-run Certbot with -v for more details.
You need an A and/or AAAA record in your DNS for your IP address. You are using an HTTP Challenge by selecting --standalone and your Google CA needs your IP to verify your domain.
3 Likes
When creating an A entry pointing to the ip of my server and running the command again I get:
The retrieval of http://test.ruttie.dev/.well-known/acme-challenge/S05fytJlXVM6gEmTPm1EdFctcDX14lzLfoRTniU-0yUS57a-KiugnKwJnJdkJDqB was rejected. Our fetch received an HTTP status code of 404.
I see an nginx server responding for http requests to that domain name. The standalone option requires exclusive use of port 80.
If you have nginx, you should use --webroot method or maybe even --nginx method. The Certbot docs explain these
https://eff-certbot.readthedocs.io/en/stable/using.html#certbot-command-line-options
You should also refer to your Google CA docs for settings related to that. We are the main support forum for Let's Encrypt CA certs.
4 Likes
So if I'm understanding this right:
- I need to stop whatever is running on port 80
- Get my certificate
- Restart whatever is running on port 80
- I now have a certificate that works for my web api
?
Depends, usually the webserver can be used to serve the challenge. But we're lacking a LOT of information. Also I'd like to mention this is the Let's Encrypt Community. Not the Google PKI Community. Now, we're nice guys and the goal of Let's Encrypt is to encrypt the entire web, regardless of choice of CA. But we might encounter a moment that we, as a Community mainly for Let's Encrypt, don't have enough knowledge about e.g. the Google PKI CA, to help you further. That as a reminder.
That said:
When you opened this thread in the Help section, you should have been provided with a questionnaire. Maybe you didn't get it somehow (which is weird), or you've decided to delete it. In any case, all the answers to this questionnaire are required:
Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
4 Likes
This is a strange error:
Did you NOT have an IP address there at the time?
Also: Don't forget to answer the questions above.
2 Likes
I managed to fix the error by running the following:
certbot --force-renewal certonly --manual -d *.ruttie.dev -d ruttie.dev --preferred-challenges dns-01
This was recommended to me by a friend.
I'm not sure if it's the right way to do it, but eh, it works.
Going forward, don't use:
From now on, you can just use:
certbot renew
2 Likes
Not with the --manual method and no manual auth hook
3 Likes
Why not simply use the --nginx plugin?
2 Likes
OR
--webroot
hmm...
Maybe because:
Do you really need a wildcard certificate?
2 Likes
Hi @ruttie,
The problem with this method (apart from the --force-renewal being unnecessary) is that it is, indeed, "manual": you have to run it yourself interactively at least every 90 days, and ideally more often than that. The DNS TXT record that you need to create will be different every time; it's not like some other verification mechanisms for other sites where a single DNS TXT record will permanently confirm your ongoing ownership of the domain name.
The other people in this thread were hoping you would provide some more information about your exact setup in order to be able to suggest commands that might be appropriate for your setup and that would be able to renew the certificate for you automatically, unlike the command that you've used.
The command that you used does get you a wildcard certificate, with the *, and the easier-to-automate methods don't (they only get you a certificate for a specific domain name or names that you specify explicitly). However, if you don't need the wildcard certificate, then it's probably easy to fully automate the process, including future certificate renewals, with an appropriate Certbot command that's going to be different than the one you've used already.
3 Likes
Okay--
Back with an update.
I installed certbot on my server, which uses nginx.
I then entered certbot --nginx and pressed enter.
This gave my a list of things to go through, which I did.
In nginx I have an entry redirecting to a different port on my server, on which my api is hosted.
I configured the api to use the same ssl files as nginx uses.
Now, when I attempt to access my api from a browser, I get a 502 message from nginx.
My api says the following: Warning: tls handshake with 127.0.0.1:40414 failed: received corrupt message.
I understand if I should ask help with this somewhere else, in which case could you tell me where?
To fill in the form:
My domain is:
hk.ruttie.dev
I ran this command:
certbot --nginx
It produced this output:
Success
My web server is (include version):
A rocket powered web api, using rocket 0.5-rc3
The operating system my web server runs on is (include version):
Ubuntu 20.04
My hosting provider, if applicable, is:
--
I can login to a root shell on my machine (yes or no, or I don't know):
yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot 0.40.0
Why are you proxying to your local server using HTTPS? Just use HTTP.
Setup a server block in nginx for HTTPS to receive the original request. Then just use HTTP to the api service on port 40414.
5 Likes
Ah, I had no idea that was possible.
Let me try it...
That worked, thanks!
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.