* Re: [9front] wildcard in auth/acmed [not found] <2CEDDEA2213DC4D744EAF757A28E45EC@driusan.net> @ 2024-01-15 17:38 ` ori 0 siblings, 0 replies; 4+ messages in thread From: ori @ 2024-01-15 17:38 UTC (permalink / raw) To: 9front, driusan, ori Quoth Dave MacFarlane <driusan@driusan.net>: > It's not a question of what challenge we request to use, > it's a question of what challenges Let's Encrypt sends > back to our request when we submit the csr. It doesn't always > match what we requested. > > It will always include a dns challenge for a wildcard > certificate, even if we request an http challenge. In the case > where I requested a wildcard and the non-subdomain certificate, > it was sending back a dns challenge for the wildcard > and an http challenge for the domain root, even if I submitted > the signing request with auth/acmed -t dns. > > The hybrid means "I don't know what the signer is going to request, > so figure it out when I get the challenge." is there a reason to keep the '-t' flag if we add logic to just figure it out? Maybe we split up the output location flags, and have one per type, and figure it out from that? ^ permalink raw reply [flat|nested] 4+ messages in thread
* [9front] wildcard in auth/acmed @ 2024-01-15 14:36 Dave MacFarlane 2024-01-15 17:02 ` ori 0 siblings, 1 reply; 4+ messages in thread From: Dave MacFarlane @ 2024-01-15 14:36 UTC (permalink / raw) To: 9front I was trying to use a Let's Encrypt certificate to host a subdomain, and the only way I could figure out how to do that was a wildcard certificate because !/bin/service/tcp443 takes the certificate as an argument before rc-httpd knows what domain it's for. A wildcard certificate for *.example.com doesn't cover example.com with no prefix, so I had to add it as a subject alternative name, but Let's Encrypt seems to ignore the -t dns and send an http-01 challenge for the non-wildcard portion and a dns-01 challenge for the wildcard. I added a "hybrid" type to auth/acmed which determines whether to use dnschallenge or httpchallenge based on the challenge, but isn't compatible with -o since dnschallenge and httpchallenge need different formats. With this, I was able to register a certificate request I created by: auth/rsa2csr 'CN=*.example.com,example.com' $certkey>$csr auth/acmed -t hybrid $username $acmeuser $csr >$crt diff 9c2e8e2b13b0d01b7adf88b61af6edfbddd872c1 uncommitted --- a/sys/src/cmd/auth/acmed.c +++ b/sys/src/cmd/auth/acmed.c @@ -633,6 +633,18 @@ } static int +hybridchallenge(char *ty, char *dom, char *tok, int *matched) +{ + if (strcmp(ty, "http-01") == 0){ + challengeout = "/usr/web/.well-known/acme-challenge"; + return httpchallenge(ty, dom, tok, matched); + } else if (strcmp(ty, "dns-01") == 0){ + challengeout = "/lib/ndb/dnschallenge"; + return dnschallenge(ty, dom, tok, matched); + } + return -1; +} +static int dochallenges(char *dom[], int ndom, JSON *order) { JSON *chals, *j, *cl, *id, *wc; @@ -910,7 +922,13 @@ }else if(strcmp(ct, "dns") == 0){ challengeout = (co != nil) ? co : "/lib/ndb/dnschallenge"; challengefn = dnschallenge; - }else { + }else if (strcmp(ct, "hybrid") == 0){ + if (co != nil) { + sysfatal("-o not compatible with hybrid challenge"); + } + challengefn = hybridchallenge; + + } else { sysfatal("unknown challenge type '%s'", ct); } ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [9front] wildcard in auth/acmed 2024-01-15 14:36 Dave MacFarlane @ 2024-01-15 17:02 ` ori 2024-01-15 17:20 ` Dave MacFarlane 0 siblings, 1 reply; 4+ messages in thread From: ori @ 2024-01-15 17:02 UTC (permalink / raw) To: 9front I'm confused about why a hybrid challenge type is needed; my read of the RFC is that we should be using DNS challenges if there's a wildcard domain name. To my knowlege, wildcards should already work (though I haven't tested in a while). As a side note, you can create one cert that covers multiple domains. For example: auth/rsa2csr 'CN=foo.example.com,bar.example.com,test.ai' $key>$csr should work just fine for any of those domains. It doesn't even need to be the same 'base' URL; This is how we get a valid cert on both https://shithub.us and https://only9fans.com; both domains serve the came cert, with CN=shithub.us,only9fans.com Quoth Dave MacFarlane <driusan@driusan.net>: > I was trying to use a Let's Encrypt certificate to host a subdomain, > and the only way I could figure out how to do that was a wildcard certificate > because !/bin/service/tcp443 takes the certificate as an argument before > rc-httpd knows what domain it's for. > > A wildcard certificate for *.example.com doesn't cover example.com > with no prefix, so I had to add it as a subject alternative name, but Let's Encrypt > seems to ignore the -t dns and send an http-01 challenge for the non-wildcard > portion and a dns-01 challenge for the wildcard. > > I added a "hybrid" type to auth/acmed which determines whether to use dnschallenge > or httpchallenge based on the challenge, but isn't compatible with -o since dnschallenge > and httpchallenge need different formats. > > With this, I was able to register a certificate request I created by: > > auth/rsa2csr 'CN=*.example.com,example.com' $certkey>$csr > auth/acmed -t hybrid $username $acmeuser $csr >$crt > > diff 9c2e8e2b13b0d01b7adf88b61af6edfbddd872c1 uncommitted > --- a/sys/src/cmd/auth/acmed.c > +++ b/sys/src/cmd/auth/acmed.c > @@ -633,6 +633,18 @@ > } > > static int > +hybridchallenge(char *ty, char *dom, char *tok, int *matched) > +{ > + if (strcmp(ty, "http-01") == 0){ > + challengeout = "/usr/web/.well-known/acme-challenge"; > + return httpchallenge(ty, dom, tok, matched); > + } else if (strcmp(ty, "dns-01") == 0){ > + challengeout = "/lib/ndb/dnschallenge"; > + return dnschallenge(ty, dom, tok, matched); > + } > + return -1; > +} > +static int > dochallenges(char *dom[], int ndom, JSON *order) > { > JSON *chals, *j, *cl, *id, *wc; > @@ -910,7 +922,13 @@ > }else if(strcmp(ct, "dns") == 0){ > challengeout = (co != nil) ? co : "/lib/ndb/dnschallenge"; > challengefn = dnschallenge; > - }else { > + }else if (strcmp(ct, "hybrid") == 0){ > + if (co != nil) { > + sysfatal("-o not compatible with hybrid challenge"); > + } > + challengefn = hybridchallenge; > + > + } else { > sysfatal("unknown challenge type '%s'", ct); > } ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [9front] wildcard in auth/acmed 2024-01-15 17:02 ` ori @ 2024-01-15 17:20 ` Dave MacFarlane 0 siblings, 0 replies; 4+ messages in thread From: Dave MacFarlane @ 2024-01-15 17:20 UTC (permalink / raw) To: ori, 9front [-- Attachment #1: Type: text/plain, Size: 654 bytes --] It's not a question of what challenge we request to use, it's a question of what challenges Let's Encrypt sends back to our request when we submit the csr. It doesn't always match what we requested. It will always include a dns challenge for a wildcard certificate, even if we request an http challenge. In the case where I requested a wildcard and the non-subdomain certificate, it was sending back a dns challenge for the wildcard and an http challenge for the domain root, even if I submitted the signing request with auth/acmed -t dns. The hybrid means "I don't know what the signer is going to request, so figure it out when I get the challenge." [-- Attachment #2: Type: message/rfc822, Size: 4616 bytes --] From: ori@eigenstate.org To: 9front@9front.org Subject: Re: [9front] wildcard in auth/acmed Date: Mon, 15 Jan 2024 12:02:39 -0500 Message-ID: <E8DF00A24335289ECDB5A610ADB1EAA7@eigenstate.org> I'm confused about why a hybrid challenge type is needed; my read of the RFC is that we should be using DNS challenges if there's a wildcard domain name. To my knowlege, wildcards should already work (though I haven't tested in a while). As a side note, you can create one cert that covers multiple domains. For example: auth/rsa2csr 'CN=foo.example.com,bar.example.com,test.ai' $key>$csr should work just fine for any of those domains. It doesn't even need to be the same 'base' URL; This is how we get a valid cert on both https://shithub.us and https://only9fans.com; both domains serve the came cert, with CN=shithub.us,only9fans.com Quoth Dave MacFarlane <driusan@driusan.net>: > I was trying to use a Let's Encrypt certificate to host a subdomain, > and the only way I could figure out how to do that was a wildcard certificate > because !/bin/service/tcp443 takes the certificate as an argument before > rc-httpd knows what domain it's for. > > A wildcard certificate for *.example.com doesn't cover example.com > with no prefix, so I had to add it as a subject alternative name, but Let's Encrypt > seems to ignore the -t dns and send an http-01 challenge for the non-wildcard > portion and a dns-01 challenge for the wildcard. > > I added a "hybrid" type to auth/acmed which determines whether to use dnschallenge > or httpchallenge based on the challenge, but isn't compatible with -o since dnschallenge > and httpchallenge need different formats. > > With this, I was able to register a certificate request I created by: > > auth/rsa2csr 'CN=*.example.com,example.com' $certkey>$csr > auth/acmed -t hybrid $username $acmeuser $csr >$crt > > diff 9c2e8e2b13b0d01b7adf88b61af6edfbddd872c1 uncommitted > --- a/sys/src/cmd/auth/acmed.c > +++ b/sys/src/cmd/auth/acmed.c > @@ -633,6 +633,18 @@ > } > > static int > +hybridchallenge(char *ty, char *dom, char *tok, int *matched) > +{ > + if (strcmp(ty, "http-01") == 0){ > + challengeout = "/usr/web/.well-known/acme-challenge"; > + return httpchallenge(ty, dom, tok, matched); > + } else if (strcmp(ty, "dns-01") == 0){ > + challengeout = "/lib/ndb/dnschallenge"; > + return dnschallenge(ty, dom, tok, matched); > + } > + return -1; > +} > +static int > dochallenges(char *dom[], int ndom, JSON *order) > { > JSON *chals, *j, *cl, *id, *wc; > @@ -910,7 +922,13 @@ > }else if(strcmp(ct, "dns") == 0){ > challengeout = (co != nil) ? co : "/lib/ndb/dnschallenge"; > challengefn = dnschallenge; > - }else { > + }else if (strcmp(ct, "hybrid") == 0){ > + if (co != nil) { > + sysfatal("-o not compatible with hybrid challenge"); > + } > + challengefn = hybridchallenge; > + > + } else { > sysfatal("unknown challenge type '%s'", ct); > } ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-01-15 17:40 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <2CEDDEA2213DC4D744EAF757A28E45EC@driusan.net> 2024-01-15 17:38 ` [9front] wildcard in auth/acmed ori 2024-01-15 14:36 Dave MacFarlane 2024-01-15 17:02 ` ori 2024-01-15 17:20 ` Dave MacFarlane
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).