| |
| ▲ | procaryote 3 days ago | parent | next [-] | | Acme dns challenge works for things that aren't webservers. For the other case perhaps renew the cert at a host allowed to do outside queries for the dns challenge and find some acceptable automated way to propagate an updated cert to the host that isn't allowed outside queries. | | |
| ▲ | Yeroc 3 days ago | parent | next [-] | | Last time I checked there's no standardized API/protocol to deal with populating the required TXT records on the DNS side. This is all fine if you've out-sourced your DNS services to one of the big players with a supported API but if you're running your own DNS services then doing automation against that is likely not going to be so easy! | | |
| ▲ | icedchai 3 days ago | parent | next [-] | | I run my own DNS servers (BIND 9.x) and use an rfc2136 plugin to handle TXT records. It works fine. See https://cert-manager.io/docs/configuration/acme/dns01/rfc213... | |
| ▲ | procaryote 2 days ago | parent | prev [-] | | One pretty easy way to do it while running your own DNS is to put the zone files, or some input that you can build to zone files, in version control. There are lots of systems that allow you to set rules for what is required to merge a PR, so if you want "the tests pass, it's a TXT record, the author is whitelisted to change that record" or something, it's very achievable |
| |
| ▲ | SoftTalker 3 days ago | parent | prev [-] | | I don't have an API or any permission to add TXT records to my DNS. That's a support ticket and has about a 24-hour turnaround best case. | | |
| ▲ | Yeroc 3 days ago | parent | next [-] | | I was just digging into this a bit and discovered ACME supports a something called DNS alias mode (https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo...) which allows you to add a static DNS TXT record on your core domain that delegates to a second domain. This would allow you to setup a second domain with DNS API (if permitted by company policy!) | |
| ▲ | immibis 3 days ago | parent | prev | next [-] | | Is this just because your DNS is with some provider, or is it something that leads from your organizational structure? If it's just because your DNS is at a provider, you should be aware that it's possible to self-host DNS. | | | |
| ▲ | JackSlateur 3 days ago | parent | prev | next [-] | | You have people paid to create DNS records ? Haha | | |
| ▲ | dijit 3 days ago | parent | next [-] | | its’ not practical to give everyone write access to the google.com root zone. Someone will fuck up accidentally, so production zones are usually gated somehow, sometimes with humans instead of pure automata. | | |
| ▲ | JackSlateur 3 days ago | parent [-] | | Why not ? Giving write access does not mean giving unrestricted write access Also, another way (which I built in a previous compagny) is to create a simple certificate provider (API or whatever), integrated with whatever internal authentication scheme you are using, and are able to sign csr for you. A LE proxy, as you might call it |
| |
| ▲ | SoftTalker 3 days ago | parent | prev [-] | | Yes we do. That’s not the only thing they do of course. | | |
| ▲ | xorcist 2 days ago | parent [-] | | It also sounds like the right people to handle certificate issuance? If you are not in a good position in the internal organization to control DNS, you probably shouldn't handle certificate issuance either. It makes sense to have a specific part of the organization responsible. |
|
| |
| ▲ | procaryote 3 days ago | parent | prev [-] | | That's not great, sorry to hear |
|
| |
| ▲ | bsder 3 days ago | parent | prev [-] | | And may the devil help you if you do something wrong and accidentally trip LetsEncrypt's rate limiting. You can do nothing except twiddle your thumbs while it times out and that may take a couple of days. |
|
