Use certbot without automatic changes to the webserver config as well as DNS server?


#1

I have the following setup currently running:

  • Google Cloud VM
  • Nginx running on that VM
  • Google Cloud DNS

I would like to use DNS based validation as I have the Google Cloud DNS running and adding a record is simpler for me than having to host stuff on the nginx webserver (which only acts as a frontend/caching server for a Java web application)

Now I’m totally lost and confused with all the plugins that seem to want to make changes to the nginx server config, reload the webserver and also automatically add DNS records to the Google Cloud DNS via Google API calls.

My (maybe too simplistic) idea was:

  • Add some record to the Google cloud DNS to prove that I’m the domain owner
  • Run certbot periodically to obtain a new certificate when the old certificate is about to expire

Is that possible at all? I don’t see the necessity to let certbot do things with my Google DNS via some API, also I don’t see the necessity to let certbot do things with my nginx server config (apart from SIGHUPing the nginx process to make it use the new certificate)

Edit: Oh, and how do I make sure everything works as expected and I don’t end up with expired certificates or something like that in 3 months in the middle of the night? Is there a way to use shorter expiration for testing?


#2

Then you don’t understand how DNS validation works. That record needs to be updated every time you renew.


#3

Hi @peterschmidt,

As @danb35 says, the reason for using an API is that the DNS record that has to be posted is different every time. In order to perform automated renewals, your Let’s Encrypt client will have to be able to make that change somehow.

Certbot edits Apache and nginx configurations because we thought that most people wanted that (and some people seem to like it a lot), but this behavior has always been optional and you’ve always been able to get the certificate only without installing it using the Certbot command certonly. There’s no requirement to have Certbot or another Let’s Encrypt client edit your web server configuration if you don’t want it to.


#4

Then you don’t understand how DNS validation works. That record needs to be updated every time you renew.

Indeed, I don’t understand why I need to prove domain ownership over and over again, is there some attack vector I may not aware of? Other services (like GSuite for example) who also rely on a TXT record for domain ownership proof also don’t require that. If I don’t have ownership of the domain anymore, the record would also be gone.

I’m not very keen on having the client access the Google DNS (or any other DNS server) as that can lead to a severe security issue (yes, I know could delegate it to some other tightly secured and/or minimal DNS server to make it more secure, but that just adds additional complexity which is more failure prone).

Only reason for this I could see is that the Letsencrypt servers don’t need to keep the content of that record (i.e. a state), however, since there already is the account ID, a state is kept already anyway.

Would you explain why that is? Is that also the case for the web based validation?

@schoen
Thanks for the info, I’ll look into the certonly option.


#6

From https://github.com/cabforum/documents/blob/master/docs/BR.md#32247-dns-change

If a Random Value is used, the CA SHALL provide a Random Value unique to the Certificate request and SHALL not use the Random Value after (i) 30 days or (ii) if the Applicant submitted the Certificate request, the timeframe permitted for reuse of validated information relevant to the Certificate (such as in Section 3.3.1 of these Guidelines or Section 11.14.3 of the EV Guidelines).

So, it’s kind of out of Let’s Encrypt’s control to begin with - all CAs are subject to this rule.

I’m not sure the comparison with G-Suite is meaningful, the validation serves an entirely less critical purpose with significantly less severe consequences.


#7

I’m not especially interested in explaining the “why”, especially since I’m not familiar with all the details behind it. But one of the reasons must surely be that domain control isn’t a permanent thing–the fact that you controlled the domain three months ago doesn’t prove that you do now. And yes, the web-based validation must also be repeated.


#8

I’m not especially interested in explaining the “why”, especially since I’m not familiar with all the details behind it. But one of the reasons must surely be that domain control isn’t a permanent thing–the fact that you controlled the domain three months ago doesn’t prove that you do now. And yes, the web-based validation must also be repeated.

That I may not control the domain anymore at some point in the future is indeed true, however, if that happens, the DNS record (or the stuff on the webserver) would also be gone.

But I guess this is not the right place for discussing the CA forum baseline requirements, don’t want to start an argument here.

Thanks for your replies guys.


#9

In case somebody is interested in the history, I think this was one of the earlier discussions on the validation working group that led to the ballots that restricted re-use: https://cabforum.org/pipermail/validation/2015-June/000034.html , though it’s not super illuminating:

Chris and I were talking, and there is the risk that a CA could complete one of these practical demonstration methods under 5, 6, and 9 in Year 1, and then go back again in 13 months (for EV) or 39 months (for DV or OV) to see if the SAME Random Value, Request Token, and Test Certificate is still there. In other words, a CA might take the liberty of doing the practical demonstration only once, and then relying on the same marker (under 5, 6, and 9) upon revetting without repeating the practical demonstration process with a new marker. I don’t think that’s a good practice.

Would be super cool if some of the history was a bit better documented, can’t disagree with Dan that the details are pretty opaque.


#10

That’s not necessarily the case, as it depends who “you” are compared to the domain owner. For an individually-owned domain, you’d generally be right, but for a corporate-owned domain, not necessarily–if the IT guy leaves the company, they aren’t going to throw out the whole infrastructure. That could result in you personally being able to issue certs for a company you don’t work for, which would be a Bad Thing™.


#11

True, but my general feeling would be: If you can’t trust your (ex) IT guy, you have other more severe problems.


#12

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