Closed cowwoc closed 3 weeks ago
cowwoc
commented
1 month ago I am requesting a new certificate for licensed.app which is a live domain, so I'm not sure why I am getting this error. I tried searching through the step-ca source-code but it's not clear to me how to debug this further. Is there additional logging I can enable to provide additional context?
cowwoc
commented
1 month ago EDIT: I've added additional logs to the original post. It shows that the requested identifier is equal to {"type":"dns","value":"licensed.app"}
cowwoc
commented
1 month ago Another thing that seems off is that the server response is HTTP 200 and status is equal to pending. I would expect the response code and order status to indicate an fatal error.
hslatman
commented
1 month ago I am requesting a new certificate for
licensed.appwhich is a live domain, so I'm not sure why I am getting this error. I tried searching through the step-ca source-code but it's not clear to me how to debug this further. Is there additional logging I can enable to provide additional context?
Did your ACME client update the DNS with the correct challenge value?
Another thing that seems off is that the server response is HTTP 200 and status is equal to pending. I would expect the response code and order status to indicate an fatal error.
This is how the ACME protocol works. Challenges are solved asynchronously, so the status is in fact pending.
cowwoc
commented
1 month ago Did your ACME client updated the DNS with the correct challenge value?
Yes. I update the DNS (hosted on Cloudflare in my case) and waited for the local machine to see the change. I then fired the challenge. Given that the server is running on the same machine as the client, I expected the challenge to succeed immediately... but it didn't. A whopping 7 minutes later, step-ca finally sees the changes. Any idea why it's taking so long?
The next problem is that the generated certificate is missing a subject. The value is an empty string for some reason. Instead, the domain name is buried under alternative names:
[
[
Version: V3
Subject:
Signature Algorithm: SHA256withECDSA, OID = 1.2.840.10045.4.3.2
Key: Sun RSA public key, 2048 bits
params: null
modulus: 18212800076484388632565845847743145593135339271155017284401740619168156935771450737113985291017383820316972032666397462774756028279124047408890648824688672799392779482841591273921864956021239968974095759114348795801487975644283090531248605416216393448796904038173248873273043520751119369097890386275499684861203338324803926978446440508322264766720974902509065309749011512919405654022717330612070977853064020089924366482684041953923148783163798969413436750672783440770469246405498863517907773697931970916946346210133151269401779495624188077057198985444875597007386235564345272448214643674498849848352158342859031219111
public exponent: 65537
Validity: [From: Tue Oct 08 14:59:44 EDT 2024,
To: Mon Jan 06 14:00:44 EST 2025]
Issuer: CN=step-ca Intermediate CA, O=step-ca
SerialNumber: [ 4cf3fcc0 28b75e51 f95b3354 1178a449]
Certificate Extensions: 6
[1]: ObjectId: 1.3.6.1.4.1.37476.9000.64.1 Criticality=false
Extension unknown: DER encoded OCTET string =
0000: 04 0D 30 0B 02 01 06 04 04 61 63 6D 65 04 00 ..0......acme..
[2]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 20 30 30 3D 45 5E D8 06 AF D0 60 42 53 D9 B8 DA 00=E^....`BS...
0010: A3 54 FD A3 .T..
]
]
[3]: ObjectId: 2.5.29.37 Criticality=false
ExtendedKeyUsages [
serverAuth
clientAuth
]
[4]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_Encipherment
]
[5]: ObjectId: 2.5.29.17 Criticality=true
SubjectAlternativeName [
DNSName: licensed.app
]
[6]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: FD B5 0C 20 49 EA C9 5F 8E D9 19 91 0F F9 F5 E4 ... I.._........
0010: E3 DE 09 B9 ....
]
]
]
Algorithm: [SHA256withECDSA]
Signature:
0000: 30 45 02 20 54 88 D1 12 8F 91 30 FB 44 FA 12 F5 0E. T.....0.D...
0010: 75 37 00 46 E5 5E 8A AC 60 92 C5 BE BB EA ED 0C u7.F.^..`.......
0020: 1B 1B 42 5A 02 21 00 B1 D0 0B BF 44 20 18 CD 82 ..BZ.!.....D ...
0030: 76 67 D8 1B 77 E3 FA B0 82 6E 42 D9 FE E4 E4 DB vg..w....nB.....
0040: FA 7D 54 25 3F E0 F3 ..T%?..
]https://github.com/smallstep/certificates/issues/302 seems to be loosely related, but I can't figure out why the subject is empty to begin with. For reference, I have been using the same client recently against Let's Encrypt and it works fine... Any ideas?
hslatman
commented
1 month ago Did your ACME client updated the DNS with the correct challenge value?
Yes. I update the DNS (hosted on Cloudflare in my case) and waited for the local machine to see the change. I then fired the challenge. Given that the server is running on the same machine as the client, I expected the challenge to succeed immediately... but it didn't. A whopping 7 minutes later, step-ca finally sees the changes. Any idea why it's taking so long?
Well, it's DNS, so there may be some caching going on 😅 Go would use the system DNS to resolve the domain. You can try the --resolver flag at startup to set a different DNS server.
The next problem is that the generated certificate is missing a
subject. The value is an empty string for some reason. Instead, the domain name is buried under alternative names:[ [ Version: V3 Subject: Signature Algorithm: SHA256withECDSA, OID = 1.2.840.10045.4.3.2 Key: Sun RSA public key, 2048 bits params: null modulus: 18212800076484388632565845847743145593135339271155017284401740619168156935771450737113985291017383820316972032666397462774756028279124047408890648824688672799392779482841591273921864956021239968974095759114348795801487975644283090531248605416216393448796904038173248873273043520751119369097890386275499684861203338324803926978446440508322264766720974902509065309749011512919405654022717330612070977853064020089924366482684041953923148783163798969413436750672783440770469246405498863517907773697931970916946346210133151269401779495624188077057198985444875597007386235564345272448214643674498849848352158342859031219111 public exponent: 65537 Validity: [From: Tue Oct 08 14:59:44 EDT 2024, To: Mon Jan 06 14:00:44 EST 2025] Issuer: CN=step-ca Intermediate CA, O=step-ca SerialNumber: [ 4cf3fcc0 28b75e51 f95b3354 1178a449] Certificate Extensions: 6 [1]: ObjectId: 1.3.6.1.4.1.37476.9000.64.1 Criticality=false Extension unknown: DER encoded OCTET string = 0000: 04 0D 30 0B 02 01 06 04 04 61 63 6D 65 04 00 ..0......acme.. [2]: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ 0000: 20 30 30 3D 45 5E D8 06 AF D0 60 42 53 D9 B8 DA 00=E^....`BS... 0010: A3 54 FD A3 .T.. ] ] [3]: ObjectId: 2.5.29.37 Criticality=false ExtendedKeyUsages [ serverAuth clientAuth ] [4]: ObjectId: 2.5.29.15 Criticality=true KeyUsage [ DigitalSignature Key_Encipherment ] [5]: ObjectId: 2.5.29.17 Criticality=true SubjectAlternativeName [ DNSName: licensed.app ] [6]: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: FD B5 0C 20 49 EA C9 5F 8E D9 19 91 0F F9 F5 E4 ... I.._........ 0010: E3 DE 09 B9 .... ] ] ] Algorithm: [SHA256withECDSA] Signature: 0000: 30 45 02 20 54 88 D1 12 8F 91 30 FB 44 FA 12 F5 0E. T.....0.D... 0010: 75 37 00 46 E5 5E 8A AC 60 92 C5 BE BB EA ED 0C u7.F.^..`....... 0020: 1B 1B 42 5A 02 21 00 B1 D0 0B BF 44 20 18 CD 82 ..BZ.!.....D ... 0030: 76 67 D8 1B 77 E3 FA B0 82 6E 42 D9 FE E4 E4 DB vg..w....nB..... 0040: FA 7D 54 25 3F E0 F3 ..T%?.. ]302 seems to be loosely related, but I can't figure out why the
subjectis empty to begin with. For reference, I have been using the same client recently against Let's Encrypt and it works fine... Any ideas?
You can use the --force-cn option (or forceCN in ca.json) to make the first identifier from the request end up in the Subject Common Name. By default we don't do that, because in Web PKI SANs are considered better to use than the Subject properties when it comes to validation of certificate chains and such, and we've taken that advice into our ACME implementation too.
maraino
commented
1 month ago Subject Alternative Names or SANs are where the domain names should be. The subject common name is deprecated but is still widely used to identify a certificate. The ACME provisioner has the forceCN property that, if set to true, it will set the CN too.
cowwoc
commented
1 month ago Oh, I see. That changes things. So if I understand you correctly, all domains get dumped into Subject Alternative Names (regardless of their order) and are given equal weight?
hslatman
commented
1 month ago Oh, I see. That changes things. So if I understand you correctly, all domains get dumped into Subject Alternative Names (regardless of their order) and are given equal weight?
It's not so much "giving a weight". They're basically (alternative) names for "the thing" that has the private key for the cert. SANs have a stronger type definition than the Subject as a whole or just its Common Name, which makes reasoning about certificate chain validation more well defined, a.o.
cowwoc
commented
1 month ago Well, it's DNS, so there may be some caching going on 😅 Go would use the system DNS to resolve the domain. You can try the --resolver flag at startup to set a different DNS server.
Thanks for reminding me... When I poll the DNS locally waiting for a change, I explicitly [disable the use of the DNS cache](https://javadoc.io/doc/dnsjava/dnsjava/latest/org/xbill/DNS/lookup/LookupSession.LookupSessionBuilder.html#clearCaches()). Does step-ca provide a similar mechanism? Can I configure it to bypass the DNS cache or only use it for a short period of time?
cowwoc
commented
1 month ago I'm going to try migrating to the http-01 challenge. Hopefully it'll be a lot faster...
cowwoc
commented
3 weeks ago Circling back, I guess you can close this issue now. Thank you.
hslatman
commented
3 weeks ago Thank you for notifying, @cowwoc 🙂
Steps to Reproduce
Use acme4j to order a new certificate using the dns-01 challenge
Your Environment
Microsoft Windows [Version 10.0.19045.4894]step-caVersion -Expected Behavior
Certificate is issued
Actual Behavior
step-ca outputs this error:
time="2024-10-08T12:59:30-04:00" level=info duration=1.0271ms duration-ns=1027100 fields.time="2024-10-08T12:59:30-04:00" method=POST name=ca nonce=SkdUMHRub1QxMndoWXJKalJYS2pIRk9wQzZ6ZU16T1E path=/acme/acme/challenge/5IFqsjAzUsVgY56A8CjuMAUxsTNImrIJ/xjMtBtRnU7tq5kpcrrYTBnrBYx1vk65V protocol=HTTP/2.0 referer= remote-address=127.0.0.1 request-id=b17f453a-ce71-4725-aef9-94036052c933 response="{\"type\":\"dns-01\",\"status\":\"pending\",\"token\":\"B1jB3SkzIrqHrbkicDzz4kMVlpM5hVdF\",\"url\":\"https://127.0.0.1:307/acme/acme/challenge/5IFqsjAzUsVgY56A8CjuMAUxsTNImrIJ/xjMtBtRnU7tq5kpcrrYTBnrBYx1vk65V\",\"error\":{\"type\":\"urn:ietf:params:acme:error:rejectedIdentifier\",\"detail\":\"The server will not issue certificates for the identifier\"}}" size=330 status=200 user-agent="acme4j/3.4.0 Java/22.0.2" user-id=Additional Context
Here is the debug log from acme4j:
Contributing
Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).