Renewing a whildcard cert created manual

Help
1

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. https://crt.sh/?q=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: srv06.tanja84.dk

I ran this command:certbot renew

It produced this output: it failed because of manual auth hook

My web server is (include version): Nginx 1.14.0

The operating system my web server runs on is (include version): Ubuntu 18.04.3

My hosting provider, if applicable, is: Linode VPS

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): 0.31.0

I have been off access to my server for to long and wanted today to generate a new or renew the certificate for *.srv06.tanja84.dk but unfortunally I can’t remember how I created it back in the days or how to renew a manual wildcard cert.

I have run apt update and apt upgrade today so the server should be fully upgraded

1 Like
2

Rather than your characterization of what happened, why not post the actual output? But if you used manual DNS validation to obtain the cert, you can't use certbot renew, because that expects to be run non-interactively and thus won't prompt you to make the DNS changes. You'll need to either re-issue the cert, or use a DNS plugin for your DNS host if one is available (or perhaps consider using a different client, like acme.sh, with better DNS support than certbot).

1 Like
3

Thanks for the response unfortunally I can’t copy the output from the server because I’m on my phone and won’t be at a computer that I trust at least for the rest of the month.

I will try to look into that then
And no I’m not trusting any systems there update dna records automatic because then access keys, password etc has to be saved on the server in plain text

1 Like
4

Then in that case you will always need to renew your certificate manually, which kind of defeats the purpose of using Let's Encrypt.

2 Likes
5

With proper DNS controls, the access "at risk" can be contained to just the TXT record for "_acme-challenge.YOUR-FQDN".
[which is really a rather limited exposure]

1 Like
6

...like acme-dns:

1 Like
7

I would not be able to use that because all my domains are registered at a Webhosting company that I trust and have prober support. So they have the dns and some of the main domains on their servers and then I have vps to some of the things there would be to expensive with them and to play around on. Also the reason that a wildcard cert would be best because sometimes I test 100 of things in docker containers just to test the systems within a week so it would be to much to have to create single domain certs for all those tests.

And again if I then had to have something updating their dns records then the full access ( the only key they have of what I know ) api key be saved or the username and password

8

...none of which has any bearing on your ability to use it.

This is exactly the situation acme-dns is intended to avoid--any credentials only allow you to create challenges for a single domain, and not to make any other DNS changes at all.

In any event, it's as I said previously--if you're stuck with (either due to lack of support, or lack of willingness, to automate) manual DNS mode, you'll need to manually renew your cert every couple of months. That really isn't how Let's Encrypt is intended to work, but it it certainly can be used that way if that's what you want to do.

1 Like
9

I have to ask you to leave this discussion because you do not want to answer the question and only want me to use your way wich I’m not going to because I do not have the education to prober run and maintain a dns Server myself and not the money to get registered as a allowed dns server in my country

10

I am disinclined to acquiesce to your request.

I have answered your question. Twice, at least. But in case it wasn't clear, here's the answer again: you'll do exactly the same thing to renew the cert that you did to issue it in the first place (certbot --manual --preferred-challenges dns certonly -d yourdomain -d \*.yourdomain, more or less) And you'll need to do it manually every time, manually updating the DNS records every time, because DNS manual mode precludes automated renewal. And you need to be aware that you are choosing to do it the hard way, when there are easier options available to you.

You have the answer to your question. What you do with it is up to you.

1 Like
11

I have created it again in the mean time with the following command

certbot certonly --manual --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory -d “*.srv06.tanja84.dk” -d srv06.tanja84.dk

And I do stand by that you are trying to push people to way less secure things so in my eyes that lets encrypt is let’s get security every were and then say just save your credentials in plain text so if for some reason you are hacked then then bad luck that your dns credentials also then is compromised

And also bad luck if your server goes down because then you lose all dns to your domains

12

You are welcome to your opinion. You are also incorrect, and demonstrating ignorance of how acme-dns works. Of course, if your existing DNS provider offers an API with granular permissions and limited-access credentials, that's great--but most don't (either don't have an API at all, or have an API that doesn't have granular access controls), and that's exactly why acme-dns was written. I do recognize the concern you state about having global API credentials deployed in cleartext, and I share it--which is why I use acme-dns in most cases. If those credentials are compromised, the attacker can only issue a cert for the domain for which they were issued--that's it. That isn't a good thing, to be sure, but it's far less of a risk than exposure of a global API key.

But however you do it, Let's Encrypt is designed for automation. Yes, you can issue manually, but you're working against the design of the system when you do so. You'll need to remember to run that command manually, and manually make the necessary DNS updates, every 60-90 days. Will it work? Yes, as long as you remember to do it.

Once again you demonstrate ignorance of what acme-dns is and how it works. I'd encourage you to read the README on its github page (I gave the link above) to avoid making such errors in the future. If your server hosting acme-dns goes down, the only problem is that your other hosts will be unable to request certs while it's down.

It's good that you're concerned about security. But when you repeatedly post that using acme-dns will expose you to risks that it was literally written to solve, when you have in front of you the information that refutes that claim, it makes it appear that your concern isn't coupled with a willingness to learn. If you don't understand it, by all means ask questions (I had trouble wrapping my head around it at first), but the statements you're making just don't demonstrate much interest in understanding.

1 Like
13

You are closing your eyes and your mind to the limitless possibilities...

  1. You could set a permanent CNAME (redirection/forwarding) - just once per domain.
    To send all your particular DNS validation requests to your personally owned/operated DNS server (Like: GitHub - joohoi/acme-dns: Limited DNS server with RESTful HTTP API to handle ACME DNS challenges easily and securely.) That can be literally turned OFF 99.9% of the time and only needs to run to validate your requests.
  2. Have you heard of 2FA (Two Factor Authentication)?
    That so called "cleartext public username and password" would be useless to anyone if any other factor was required - like: Source IP address.

I think you have been quick to judge or unduly influenced by some bad experience or bad information.

1 Like
14

And you are also misinformed and funny to listen to with all those false statements you are spreading

Sure there is things like 2FA but that is out of the question because automated systems does not have Two Factor Authentication like UbiKey, Google Authenticator or Authy because then it can’t be automated, because then you have to put in the second authentication and that breaks it. And it’s still a issue even when it’s only api key because if the hacker knows about how the system then it’s still a way to gain access to information and perhaps change over http/https protocol

And no if a hacker is there where he is able to see the password/api key then it would be very easy for him to proxy his connection throug the server so the destination still gets the ip of the server instead of the hackers ip.

Then we have the GitHub project that has so many flaws in it self.
Only a github by community ( actually only able to see one person on my mobile but it could be a issue on mobile ) there could be left tomorrow for all I know, build on a language where there is no packages anywhere ( only manual installer from creator of go ) so almost impossible to keep up to date ( big security risk ), no audits report of what I have seen and no I can’t audit it myself because I do not know the language go, and also don’t have the time for it.

And if you say well it’s only internal it’s used then I would say many also thought that about bash ( born again shell ) and then I would say try thinking back to the major security flaw there were in 2014 Shellshock, so if bash then just were installed from source and not maintained packages how many even today would then still be affected by it.

Then I also have the issue that it spawns a dns server and has to use port 53, well I allready have bind running for internal use to easier maintain my servers to when I connect in to maintain over openvpn.

Just to mention some of the things

15

You’re running BIND? It has really excellent access controls for dynamic updates. Have you tried it and run into limitations that won’t work for you?

2 Likes
16

I run bind bot internal use not for public use again I’m not a dns engineer or administrator so the port is further more directly blocked on purpose on external ip in the firewall what part of that did you not understand

Bind are only allowed on private ips and the management openvpn network to not risking further mistakes

17

He literally gave you an example of 2FA that an automated system could easily have.

Yes, and Microsoft might turn into a smoking crater tomorrow. If and when that happens, and nobody picks up the project, you could consider alternatives.

Yes, there are. I know because I maintain them (see RepoView: DanB35 Repo). Or you can download the compiled binary (that's a nice thing about Go, it builds statically-linked binaries that require no installation beyond putting the binary in whatever directory you want to run it from), assuming you're running Linux. Or you can build it yourself if (1) you're using Linux and just want to, or (2) you aren't using Linux and haven't found a package for your OS.

Not at all, see above. Even if you aren't using a package, download the compiled binary, copy it over the old version, done.

AFAIK, you're right. Do you require a security audit for every piece of software on your server?

It isn't only internal; it must serve DNS externally--that's its entire purpose.

...and acme-dns serves DNS externally, so there's no conflict there. Or you could probably configure bind to serve only the validation records externally, but I'll admit I have no idea how that would be done.

And as already mentioned, but worth repeating: acme-dns would only need to be running when you're actually validating a domain; it can be shut down the rest of the time. If you're as concerned about its security as you say, this would be a trivial thing to have certbot do (start acme-dns, run the validation, issue the cert, stop acme-dns).

I'm sure he understood none of that at the time he posted, since you hadn't said it previously.

The more you write, the more obvious it becomes that you simply don't understand what you're talking about (as you, blind to the irony, accuse others of making false statements which you never quite manage to identify). How you administer your servers is, of course, up to you, and as long as it isn't resulting in a DDOS or other attack against my servers, I don't much care. But you seem bound and determined to go about this the hard way, while raising objections that are, to be frank, nonsensical. If you're a masochist, hey, knock yourself out and do it the hard way. But if not, it'd be worth some time to read and learn that there's a secure way to do it much more easily.

2 Likes
18

I would like to add to this, If he has an absolute objection to automation and will not consider it in any shape or form, even securely as was already suggested (for reasons I can’t understand), Let’s Encrypt may not be the best solution to fit his needs.

Attempting to use LE without automation can degrade security as users can used to clicking through warnings or setting exceptions on their devices when the cert expires or as a longer shot manipulating the certificate through multiple machines (i.e. website like zerossl --> desktop --> server) can present more points for a malicious party to steal the private key.

A paid certificate with a longer validity might work better for this situation.

1 Like
19

With CAA a MITM can still issue cert for his system - LOL

20

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.