Migrate from dehydrated to certbot

Help
1

Hi,

I was planning to migrate from dehydrated to certbot for Challange-Type: DNS-01.

I would like to preserve my privkey.pem and maybe the cert.csr from dehydrated to the next renewal with certbot

Is the only thing I have to do to, changing the files at

  • /etc/letsencrypt/archive/tachtler.net/privkey1.pem
  • /etc/letsencrypt/keys/0000_key-certbot.pem
  • /etc/letsencrypt/csrs/0000_csr-certbot.pem

and start a certificate challenge or a renewal?

Thank you for any advice!
Klaus.

1 Like
2

Do you have a good reason to do that?

Even when reusing the private key, the advice is to rotate it annually.

2 Likes
3

The /keys/ and /csr/ directories are useless: they are not used for renewals.

That said, there is no easy way to migrate from another ACME client to Certbot: you'd have to manually write the renewal configuration file. Renewal also uses the original certificate. Basically, you'd have to recreate an existing certificate generated by Certbot. If any of the many details is incorrect, Certbot will malfunction.

3 Likes
4

Hi 9peppe,

yes, the reason is to use my existing TLSA-Records, like described here:
Please avoid “3 0 1” and “3 0 2” DANE TLSA records with LE certificates

Thank you!
Klaus.

1 Like
5

Hi Osiris,

please, can you explain "manually rewrite the renewal configuration file"?

Maybe, I was creating a certificate request with --test-cert against the "STAGING" environment and change after that the

  • /etc/letsencrypt/archive/tachtler.net/privkey1.pem
  • /etc/letsencrypt/keys/0000_key-certbot.pem
  • /etc/letsencrypt/csrs/0000_csr-certbot.pem

and start a renewal with --force-renew?

Do you think that could work? (Or simply, I have to try it?)

Thank you in advance!
Klaus.

1 Like
6

Hi,

in the end, I'll have to do the following, to avoid the mistakes described below, what do you think?

Failure to update TLSA records before updating the matching server certificate chain (deploying a new server key pair, or using a new issuing CA)

Thank you again, in advance!
Klaus.

1 Like
7

Very low probability.

You will definitely have to "try it".
Backup your current files and then make the test(s).
[beware of issuing more than 4 certs in a one week period - so limit your tests]
That said, I would adjust your "test" by removing the .csr file(s) and letting certbot create a new one.

1 Like
8

Add more TLSA records. :slight_smile:

❯ dig TLSA _25._tcp.bjorn.qualcuno.xyz

; <<>> DiG 9.16.27 <<>> TLSA _25._tcp.bjorn.qualcuno.xyz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65020
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;_25._tcp.bjorn.qualcuno.xyz.   IN      TLSA

;; ANSWER SECTION:
_25._tcp.bjorn.qualcuno.xyz. 10773 IN   TLSA    2 1 1 4179EDD981EF747477B49626408AF43DAA2CA7AB7F9E082C1060F840 96774348
_25._tcp.bjorn.qualcuno.xyz. 10773 IN   TLSA    2 1 1 871A9194F4EED5B312FF40C84C1D524AED2F778BBFF25F138CF81F68 0A7ADC67
_25._tcp.bjorn.qualcuno.xyz. 10773 IN   TLSA    2 1 1 0B9FA5A59EED715C26C1020C711B4F6EC42D58B0015E14337A39DAD3 01C5AFC3
_25._tcp.bjorn.qualcuno.xyz. 10773 IN   TLSA    2 1 1 9847E5653E5E9E847516E5CB818606AA7544A19BE67FD7366D506988 E8D84347
_25._tcp.bjorn.qualcuno.xyz. 10773 IN   TLSA    2 1 1 55F77DE41C03792428F8D518C55104225BE43A5598D926A528AD653E 1CCEC7BF
_25._tcp.bjorn.qualcuno.xyz. 10773 IN   TLSA    2 1 1 08B3A6335FCE5EF48F8F0E543986C07FD18A3B1226129F61864BBD5B DD1F1CC9
_25._tcp.bjorn.qualcuno.xyz. 10773 IN   TLSA    2 1 1 762195C225586EE6C0237456E2107DC54F1EFC21F61A792EBD515913 CCE68332

;; Query time: 23 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun May 08 07:49:29 CEST 2022
;; MSG SIZE  rcvd: 385
9

I think that could work, although I'm not sure it will work. For example, I already told you the files in the /keys/ and /csr/ directory aren't used. Also, you'd need to fetch your staging cert with the exact correct options to e.g. prevent Certbot from generating a new private key with each renewal. It can be done, you just need to be very correct about everything.

It's probably way easier to just add another TLSA RR as @9peppe already suggested.

2 Likes
10

And you can just pin the roots, instead of the leaf certificate. My records there, they're pinning the public keys for ISRG Root X1, ISRG Root X2, and all GTS roots.

11

"Can"... yes.
But should they? Would you recommend doing that (if so, why)?

1 Like
12

Yeah, why not?

DANE isn't HPKP, and pinning the roots in there is just a client-side enforcement of CAA. (where the client is the MUA connecting to your MTA, since MTAs are the only actual users of DANE.)

1 Like
13

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