starred/dehydrated
1
0
Fork 0
mirror of https://github.com/dehydrated-io/dehydrated.git synced 2026-01-11 22:30:44 +01:00
Code Issues 79 Packages Projects Releases 10 Wiki Activity

Cannot use --signcsr : "Invalid character in DNS name" #381

New Issue
Closed
opened 2025-12-29 01:24:02 +01:00 by adam · 11 comments
adam commented 2025-12-29 01:24:02 +01:00
Owner
Copy Link

Originally created by @bortzmeyer on GitHub (Sep 25, 2018).

I can use dehydrated --cron --domain www.bortzmeyer.org for my domain and it works. Now, I want to use my own CSR and I try --signcsr:

% sudo dehydrated --signcsr ./blog.csr --domain www.bortzmeyer.org
# INFO: Using main config file /etc/dehydrated/config                        
# !! WARNING !! Extra configuration directory /etc/dehydrated/conf.d exists, but no configuration found in it.
 + Requesting challenge for Subject:...
  + ERROR: An error occurred while sending post-request to https://acme-v01.api.letsencrypt.org/acme/new-authz (Status 400)

Details:
{
  "type": "urn:acme:error:malformed",
  "detail": "Error creating new authz :: Invalid character in DNS name",
  "status": 400
}

rm: cannot remove '/etc/dehydrated/domains.txt': No such file or directory

The domain name seems perfectly OK (and it works with --cron). In the CSR:

% openssl req -text -in blog.csr                                                              
Certificate Request:                   
    Data:
        Version: 1 (0x0)
        Subject: CN = www.bortzmeyer.org
...

It seems the same subject as in the CSR generated by dehydrated --cron.

I tried with a ECDSA CSR and a RSA one, same result.

I'm not sure it is a dehydrated bug, of course, it can be a Let's Encrypt one, or a fault on my side but I cannot find it.

Originally created by @bortzmeyer on GitHub (Sep 25, 2018). I can use `dehydrated --cron --domain www.bortzmeyer.org` for my domain and it works. Now, I want to use my own CSR and I try `--signcsr`: ``` % sudo dehydrated --signcsr ./blog.csr --domain www.bortzmeyer.org # INFO: Using main config file /etc/dehydrated/config # !! WARNING !! Extra configuration directory /etc/dehydrated/conf.d exists, but no configuration found in it. + Requesting challenge for Subject:... + ERROR: An error occurred while sending post-request to https://acme-v01.api.letsencrypt.org/acme/new-authz (Status 400) Details: { "type": "urn:acme:error:malformed", "detail": "Error creating new authz :: Invalid character in DNS name", "status": 400 } rm: cannot remove '/etc/dehydrated/domains.txt': No such file or directory ``` The domain name seems perfectly OK (and it works with `--cron`). In the CSR: ``` % openssl req -text -in blog.csr Certificate Request: Data: Version: 1 (0x0) Subject: CN = www.bortzmeyer.org ... ``` It seems the same subject as in the CSR generated by `dehydrated --cron`. I tried with a ECDSA CSR and a RSA one, same result. I'm not sure it is a dehydrated bug, of course, it can be a Let's Encrypt one, or a fault on my side but I cannot find it.
adam closed this issue 2025-12-29 01:24:02 +01:00
adam commented 2025-12-29 01:24:03 +01:00
Author
Owner
Copy Link

@cpu commented on GitHub (Sep 25, 2018):

👋 @bortzmeyer

Can you share the full CSR? Are the Subject Alternate Names well formed?

I'm not sure it is a dehydrated bug, of course, it can be a Let's Encrypt one, or a fault on my side but I cannot find it.

I can at least rule out that its a bug with Let's Encrypt :-)

In the server side logs I can see that Dehydrated POSTed new-authz with an invalid domain identifier in the authenticated JWS body:

"identifier": {"type": "dns", "value": "Subject:"}

I can't tell where the "Subject:" value came from: a bug with Dehydrated, a problem with the CSR, or both. It should be a domain name instead.

@cpu commented on GitHub (Sep 25, 2018): :wave: @bortzmeyer Can you share the full CSR? Are the Subject Alternate Names well formed? > I'm not sure it is a dehydrated bug, of course, it can be a Let's Encrypt one, or a fault on my side but I cannot find it. I can at least rule out that its a bug with Let's Encrypt :-) In the server side logs I can see that Dehydrated POSTed new-authz with an invalid domain identifier in the authenticated JWS body: > "identifier": {"type": "dns", "value": "Subject:"} I can't tell where the `"Subject:"` value came from: a bug with Dehydrated, a problem with the CSR, or both. It should be a domain name instead.
adam commented 2025-12-29 01:24:04 +01:00
Author
Owner
Copy Link

@bortzmeyer commented on GitHub (Sep 25, 2018):

Oh, yes, I should have send the full CSR. Here it is:

-----BEGIN CERTIFICATE REQUEST-----
MIHWMH8CAQAwHTEbMBkGA1UEAwwSd3d3LmJvcnR6bWV5ZXIub3JnMFkwEwYHKoZI
zj0CAQYIKoZIzj0DAQcDQgAE+i8wLn3mwWMJ1S8zw+lIyiWvpZ9iNVZ3aiq4omoG
ZpUtF0blitUXKhYLUOmofQwrFqb7YNFZ0qHFXIWQJRMXA6AAMAoGCCqGSM49BAMC
A0cAMEQCIGffhXFGK4TrqkQ5P0lGzwTRJQA8qCMkE9UOWgZ9gdx1AiAgU+ilYgTG
510OonzEqJ0izvfwRwiglGZ8yaZHun1+Zg==
-----END CERTIFICATE REQUEST-----

This is the ECDSA one, but the RSA one triggers the same error.

@bortzmeyer commented on GitHub (Sep 25, 2018): Oh, yes, I should have send the full CSR. Here it is: ``` -----BEGIN CERTIFICATE REQUEST----- MIHWMH8CAQAwHTEbMBkGA1UEAwwSd3d3LmJvcnR6bWV5ZXIub3JnMFkwEwYHKoZI zj0CAQYIKoZIzj0DAQcDQgAE+i8wLn3mwWMJ1S8zw+lIyiWvpZ9iNVZ3aiq4omoG ZpUtF0blitUXKhYLUOmofQwrFqb7YNFZ0qHFXIWQJRMXA6AAMAoGCCqGSM49BAMC A0cAMEQCIGffhXFGK4TrqkQ5P0lGzwTRJQA8qCMkE9UOWgZ9gdx1AiAgU+ilYgTG 510OonzEqJ0izvfwRwiglGZ8yaZHun1+Zg== -----END CERTIFICATE REQUEST----- ``` This is the ECDSA one, but the RSA one triggers the same error.
adam commented 2025-12-29 01:24:04 +01:00
Author
Owner
Copy Link

@bllfr0g commented on GitHub (Sep 25, 2018):

This CSR has no SAN(s) defined. At the very least, have one SAN equal to the CN and I bet you’ll be good.

On Sep 25, 2018, at 13:02, Stéphane Bortzmeyer notifications@github.com wrote:

Oh, yes, I should have send the full CSR. Here it is:

-----BEGIN CERTIFICATE REQUEST-----
MIHWMH8CAQAwHTEbMBkGA1UEAwwSd3d3LmJvcnR6bWV5ZXIub3JnMFkwEwYHKoZI
zj0CAQYIKoZIzj0DAQcDQgAE+i8wLn3mwWMJ1S8zw+lIyiWvpZ9iNVZ3aiq4omoG
ZpUtF0blitUXKhYLUOmofQwrFqb7YNFZ0qHFXIWQJRMXA6AAMAoGCCqGSM49BAMC
A0cAMEQCIGffhXFGK4TrqkQ5P0lGzwTRJQA8qCMkE9UOWgZ9gdx1AiAgU+ilYgTG
510OonzEqJ0izvfwRwiglGZ8yaZHun1+Zg==
-----END CERTIFICATE REQUEST-----
This is the ECDSA one, but the RSA one triggers the same error.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@bllfr0g commented on GitHub (Sep 25, 2018): This CSR has no SAN(s) defined. At the very least, have one SAN equal to the CN and I bet you’ll be good. > On Sep 25, 2018, at 13:02, Stéphane Bortzmeyer <notifications@github.com> wrote: > > Oh, yes, I should have send the full CSR. Here it is: > > -----BEGIN CERTIFICATE REQUEST----- > MIHWMH8CAQAwHTEbMBkGA1UEAwwSd3d3LmJvcnR6bWV5ZXIub3JnMFkwEwYHKoZI > zj0CAQYIKoZIzj0DAQcDQgAE+i8wLn3mwWMJ1S8zw+lIyiWvpZ9iNVZ3aiq4omoG > ZpUtF0blitUXKhYLUOmofQwrFqb7YNFZ0qHFXIWQJRMXA6AAMAoGCCqGSM49BAMC > A0cAMEQCIGffhXFGK4TrqkQ5P0lGzwTRJQA8qCMkE9UOWgZ9gdx1AiAgU+ilYgTG > 510OonzEqJ0izvfwRwiglGZ8yaZHun1+Zg== > -----END CERTIFICATE REQUEST----- > This is the ECDSA one, but the RSA one triggers the same error. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub, or mute the thread.
adam commented 2025-12-29 01:24:05 +01:00
Author
Owner
Copy Link

@cpu commented on GitHub (Sep 25, 2018):

@bllfr0g That part of the CSR @bortzmeyer shared stands out to me as well, but it does appear based on a quick skim of the Dehydrated source that this case should be handled: fba49ba28e/dehydrated (L644-L648)

I'm afraid we're outside of my depth now. It seems to me to be a Dehydrated bug so I'm going to drop off this thread with the hope a maintainer can take over from here.

Good luck!

@cpu commented on GitHub (Sep 25, 2018): @bllfr0g That part of the CSR @bortzmeyer shared stands out to me as well, but it does appear based on a quick skim of the Dehydrated source that this case _should_ be handled: https://github.com/lukas2511/dehydrated/blob/fba49ba28eb746eae127aa36e7f515beeaf0bbae/dehydrated#L644-L648 I'm afraid we're outside of my depth now. It seems to me to be a Dehydrated bug so I'm going to drop off this thread with the hope a maintainer can take over from here. Good luck!
adam commented 2025-12-29 01:24:06 +01:00
Author
Owner
Copy Link

@bllfr0g commented on GitHub (Sep 25, 2018):

I don’t think dehydrated is balking on the CSR, I think LetsEncrypt is. Nothing dehydrated can do to fix that.

On Sep 25, 2018, at 13:20, Daniel McCarney notifications@github.com wrote:

@bllfr0g That part of the CSR @bortzmeyer shared stands out to me as well, but it does appear based on a quick skim of the Dehydrated source that this case should be handled: fba49ba28e/dehydrated (L644-L648)

I'm afraid we're outside of my depth now. It seems to me to be a Dehydrated bug so I'm going to drop off this thread with the hope a maintainer can take over from here.

Good luck!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@bllfr0g commented on GitHub (Sep 25, 2018): I don’t think dehydrated is balking on the CSR, I think LetsEncrypt is. Nothing dehydrated can do to fix that. > On Sep 25, 2018, at 13:20, Daniel McCarney <notifications@github.com> wrote: > > @bllfr0g That part of the CSR @bortzmeyer shared stands out to me as well, but it does appear based on a quick skim of the Dehydrated source that this case should be handled: https://github.com/lukas2511/dehydrated/blob/fba49ba28eb746eae127aa36e7f515beeaf0bbae/dehydrated#L644-L648 > > I'm afraid we're outside of my depth now. It seems to me to be a Dehydrated bug so I'm going to drop off this thread with the hope a maintainer can take over from here. > > Good luck! > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or mute the thread.
adam commented 2025-12-29 01:24:07 +01:00
Author
Owner
Copy Link

@cpu commented on GitHub (Sep 25, 2018):

I don’t think dehydrated is balking on the CSR, I think LetsEncrypt is. Nothing dehydrated can do to fix that.

@bllfr0g Sorry, I should have made my affiliation clearer. I work for Let's Encrypt and verified from the server-side Let's Encrypt logs that this is not the case.

Dehydrated is processing the CSR and something strange happens that results in an ACME request to the Let's Encrypt ACME server's new-authz endpoint with an invalid identifier value. The CSR isn't sent to Let's Encrypt (in the ACME v1 world) until the new-cert POST and the error is occurring before then so we can say with double confidence it isn't Let's Encrypt rejecting the CSR.

@cpu commented on GitHub (Sep 25, 2018): > I don’t think dehydrated is balking on the CSR, I think LetsEncrypt is. Nothing dehydrated can do to fix that. @bllfr0g Sorry, I should have made my affiliation clearer. I work for Let's Encrypt and verified from the server-side Let's Encrypt logs that this is not the case. Dehydrated is processing the CSR and something strange happens that results in an ACME request to the Let's Encrypt ACME server's new-authz endpoint with an invalid identifier value. The CSR isn't sent to Let's Encrypt (in the ACME v1 world) until the new-cert POST and the error is occurring before then so we can say with double confidence it isn't Let's Encrypt rejecting the CSR.
adam commented 2025-12-29 01:24:09 +01:00
Author
Owner
Copy Link

@lukas2511 commented on GitHub (Sep 26, 2018):

Mh... @bortzmeyer what OS are you running dehydrated on? Can you please post the output of dehydrated -v?

@lukas2511 commented on GitHub (Sep 26, 2018): Mh... @bortzmeyer what OS are you running dehydrated on? Can you please post the output of `dehydrated -v`?
adam commented 2025-12-29 01:24:09 +01:00
Author
Owner
Copy Link

@bortzmeyer commented on GitHub (Sep 26, 2018):

Mh... @bortzmeyer what OS are you running dehydrated on? Can you please post the output of dehydrated -v?

% cat /etc/debian_version 
9.5

% dehydrated -v
Unknown parameter detected: -v

Usage: /usr/bin/dehydrated [-h] [command [argument]] [parameter [argument]] [parameter [argument]] ...

Default command: help

Commands:
 --cron (-c)                      Sign/renew non-existant/changed/expiring certificates.
 --signcsr (-s) path/to/csr.pem   Sign a given CSR, output CRT on stdout (advanced usage)
 --revoke (-r) path/to/cert.pem   Revoke specified certificate
 --cleanup (-gc)                  Move unused certificate files to archive directory
 --help (-h)                      Show help text
 --env (-e)                       Output configuration variables for use in other scripts

Parameters:
 --full-chain (-fc)               Print full chain when using --signcsr
 --ipv4 (-4)                      Resolve names to IPv4 addresses only
 --ipv6 (-6)                      Resolve names to IPv6 addresses only
 --domain (-d) domain.tld         Use specified domain name(s) instead of domains.txt entry (one certificate!)
 --keep-going (-g)                Keep going after encountering an error while creating/renewing multiple certificates in cron mode
 --force (-x)                     Force renew of certificate even if it is longer valid than value in RENEW_DAYS
 --no-lock (-n)                   Don't use lockfile (potentially dangerous!)
 --ocsp                           Sets option in CSR indicating OCSP stapling to be mandatory
 --privkey (-p) path/to/key.pem   Use specified private key instead of account key (useful for revocation)
 --config (-f) path/to/config     Use specified config file
 --hook (-k) path/to/hook.sh      Use specified script for hooks
 --out (-o) certs/directory       Output certificates into the specified directory
 --challenge (-t) http-01|dns-01  Which challenge should be used? Currently http-01 and dns-01 are supported
 --algo (-a) rsa|prime256v1|secp384r1 Which public key algorithm should be used? Supported: rsa, prime256v1 and secp384r1
@bortzmeyer commented on GitHub (Sep 26, 2018): > Mh... @bortzmeyer what OS are you running dehydrated on? Can you please post the output of `dehydrated -v`? ``` % cat /etc/debian_version 9.5 % dehydrated -v Unknown parameter detected: -v Usage: /usr/bin/dehydrated [-h] [command [argument]] [parameter [argument]] [parameter [argument]] ... Default command: help Commands: --cron (-c) Sign/renew non-existant/changed/expiring certificates. --signcsr (-s) path/to/csr.pem Sign a given CSR, output CRT on stdout (advanced usage) --revoke (-r) path/to/cert.pem Revoke specified certificate --cleanup (-gc) Move unused certificate files to archive directory --help (-h) Show help text --env (-e) Output configuration variables for use in other scripts Parameters: --full-chain (-fc) Print full chain when using --signcsr --ipv4 (-4) Resolve names to IPv4 addresses only --ipv6 (-6) Resolve names to IPv6 addresses only --domain (-d) domain.tld Use specified domain name(s) instead of domains.txt entry (one certificate!) --keep-going (-g) Keep going after encountering an error while creating/renewing multiple certificates in cron mode --force (-x) Force renew of certificate even if it is longer valid than value in RENEW_DAYS --no-lock (-n) Don't use lockfile (potentially dangerous!) --ocsp Sets option in CSR indicating OCSP stapling to be mandatory --privkey (-p) path/to/key.pem Use specified private key instead of account key (useful for revocation) --config (-f) path/to/config Use specified config file --hook (-k) path/to/hook.sh Use specified script for hooks --out (-o) certs/directory Output certificates into the specified directory --challenge (-t) http-01|dns-01 Which challenge should be used? Currently http-01 and dns-01 are supported --algo (-a) rsa|prime256v1|secp384r1 Which public key algorithm should be used? Supported: rsa, prime256v1 and secp384r1 ```
adam commented 2025-12-29 01:24:09 +01:00
Author
Owner
Copy Link

@bortzmeyer commented on GitHub (Sep 26, 2018):

OK, I regenerated the CSR with:

openssl req -new -key blog.pem  -nodes -days 1000 -subj '/CN=www.bortzmeyer.org' -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:www.bortzmeyer.org")) -out blog.csr

Now, there is a SAN:

        Attributes:
        Requested Extensions:
            X509v3 Subject Alternative Name: 
                DNS:www.bortzmeyer.org

And this time, dehydrated makes a correct request and Let's Encrypt signs the certificate. Hooray.

Suggestion: dehydrated should produce a proper error message such as "Missing Subject Alternative Name in the CSR" (or generate the domain name from the CN if there is no SAN).

@bortzmeyer commented on GitHub (Sep 26, 2018): OK, I regenerated the CSR with: ``` openssl req -new -key blog.pem -nodes -days 1000 -subj '/CN=www.bortzmeyer.org' -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:www.bortzmeyer.org")) -out blog.csr ``` Now, there is a SAN: ``` Attributes: Requested Extensions: X509v3 Subject Alternative Name: DNS:www.bortzmeyer.org ``` And this time, dehydrated makes a correct request and Let's Encrypt signs the certificate. Hooray. Suggestion: dehydrated should produce a proper error message such as "Missing Subject Alternative Name in the CSR" (or generate the domain name from the CN if there is no SAN).
adam commented 2025-12-29 01:24:10 +01:00
Author
Owner
Copy Link

@txr13 commented on GitHub (Sep 26, 2018):

@bortzmeyer You’re using a really, really old version of dehydrated, if it doesn’t even support the “version” command. You really should consider using the current version instead, which has obviously fixed many bugs (and added some new features).

Edit: Yeah, Debian Stretch has dehydrated 0.3.1 packaged, while dehydrated is currently on 0.6.2.

@txr13 commented on GitHub (Sep 26, 2018): @bortzmeyer You’re using a really, really old version of dehydrated, if it doesn’t even support the “version” command. You really should consider using the current version instead, which has obviously fixed many bugs (and added some new features). Edit: Yeah, Debian Stretch has dehydrated 0.3.1 packaged, while dehydrated is currently on 0.6.2.
adam commented 2025-12-29 01:24:10 +01:00
Author
Owner
Copy Link

@lukas2511 commented on GitHub (Oct 20, 2018):

Like @txr13 said this issue was already fixed quite a while ago.
Please update your version of dehydrated, it's just a shell-script so it shouldn't be much of a problem to "install" manually.

@lukas2511 commented on GitHub (Oct 20, 2018): Like @txr13 said this issue was already fixed quite a while ago. Please update your version of dehydrated, it's just a shell-script so it shouldn't be much of a problem to "install" manually.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Complicated
bug
enhancement
help wanted
pull-request
Mirrored from GitHub Pull Request
 suggestions wanted
testing
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#381
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?