search

acmesh-official / acme.sh

A pure Unix shell script implementing ACME client protocol
https://acme.sh
GNU General Public License v3.0
38.67k stars 4.91k forks source link

Feature Request: Wildcard Support #934

Open sjau opened 7 years ago

sjau commented 7 years ago

LE has just announced that it will start to offer wildcard certs from january 2018.

Just to keep that in mind, I already open this feature request.

https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html

"Let’s Encrypt will begin issuing wildcard certificates in January of 2018. Wildcard certificates are a commonly requested feature and we understand that there are some use cases where they make HTTPS deployment easier. Our hope is that offering wildcards will help to accelerate the Web’s progress towards 100% HTTPS."

ghost commented 7 years ago

This requires ACME V2 API support.

Neilpang commented 7 years ago

There is not too much difference between v2 and v1 for now.

Let's wait then.

sjau commented 7 years ago

As said, it's just a feature request so that it won't get forgotten :) But I'm happy to hear that v2 isn't too different from v1.

kimchirichie commented 7 years ago

I was hoping this was already implemented. this feature is definitely wanted

FernandoMiguel commented 6 years ago

@Neilpang is there a ticket to track support of acme.sh for acme v2?

FernandoMiguel commented 6 years ago

https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md

Neilpang commented 6 years ago

@FernandoMiguel Not yet. but there is not too much differences in V2.

itsacorn commented 6 years ago

Any updates on this?

FernandoMiguel commented 6 years ago

@itsacorn acme 2.0 will only be available next year

itsacorn commented 6 years ago

@FernandoMiguel Yeah, next year is in a few days and its coming out in january. I need this feature as soon as possible, so as soon as wildcards are rolled out i can get a certificate. Its annoying to re-issue a certificate each time a new user joins your image hosting service.

FernandoMiguel commented 6 years ago

Last I heard, LE is releasing wildcard in February

FernandoMiguel commented 6 years ago

https://letsencrypt.org/2017/12/07/looking-forward-to-2018.html

FernandoMiguel commented 6 years ago

First, we’re planning to introduce an ACME v2 protocol API endpoint and support for wildcard certificates along with it. Wildcard certificates will be free and available globally just like our other certificates. We are planning to have a public test API endpoint up by January 4, and we’ve set a date for the full launch: Tuesday, February 27.

itsacorn commented 6 years ago

@FernandoMiguel Thanks for that blog post, havent seen it before. Do you know if it means that the test API will feature the full normal LE certification root? Or will it have the "Fake LE" one? This is a deal-breaker for me.

sjau commented 6 years ago

public test API -> no real cert I guess, just like back in the beta....

Also, it's DNS-01 only.

Neilpang commented 6 years ago

we have a new branch for ACME v2 now:

https://github.com/Neilpang/acme.sh/tree/2

Usage: https://community.letsencrypt.org/t/now-acme-sh-speaks-acme-v2/49671/2 https://community.letsencrypt.org/t/acme-sh-supports-acme-v2-wildcard-now/49685

sjau commented 6 years ago

Awesome - thank you for your hard work thumbs up

sjau commented 6 years ago

Just tested it and it works:

root@manager ~ # adduser acme2
Adding user `acme2' ...
Adding new group `acme2' (1006) ...
Adding new user `acme2' (1006) with group `acme2' ...
Creating home directory `/home/acme2' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for acme2
Enter the new value, or press ENTER for the default
Full Name []:
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n] y
root@manager ~ # su acme2
bash: alias: -wSc: not found
acme2@manager:/root$ cd /home/acme2/
acme2@manager:~$ git clone https://github.com/Neilpang/acme.sh.git
Cloning into 'acme.sh'...
remote: Counting objects: 5355, done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 5355 (delta 4), reused 6 (delta 2), pack-reused 5343
Receiving objects: 100% (5355/5355), 1.99 MiB | 0 bytes/s, done.
Resolving deltas: 100% (2893/2893), done.
acme2@manager:~$ cd acme.sh/
acme2@manager:~/acme.sh$ git checkout 2 
Branch 2 set up to track remote branch 2 from origin.
Switched to a new branch '2' 
acme2@manager:~/acme.sh$ ./acme.sh --install 
[Sat Jan6 11:56:33 CET 2018] Installing to /home/acme2/.acme.sh
[Sat Jan6 11:56:33 CET 2018] Installed to /home/acme2/.acme.sh/acme.sh 
[Sat Jan6 11:56:33 CET 2018] Installing alias to '/home/acme2/.bashrc' 
[Sat Jan6 11:56:33 CET 2018] OK, Close and reopen your terminal to start using acme.sh 
[Sat Jan6 11:56:33 CET 2018] Installing cron job 
no crontab for acme2 
no crontab for acme2 
[Sat Jan6 11:56:33 CET 2018] Good, bash is found, so change the shebang to use bash as preferred.
[Sat Jan6 11:56:34 CET 2018] OK
acme2@manager:~/acme.sh$ exit
exit 
root@manager ~ # su acme2
acme2@manager:/root$ cd /home/acme2/
acme2@manager:~$ which acme.sh 
acme2@manager:~$ 
acme2@manager:~$ export ISPC_User="xxx"
acme2@manager:~$ export ISPC_Password="xxx"
acme2@manager:~$ export ISPC_Api="https://manager.roleplayer.org:8080/remote/json.php"
acme2@manager:~$ export ISPC_Api_Insecure="0"
acme2@manager:~$ acme.sh --test --issue -d roleplayer.org -d *.roleplayer.org --dns dns_ispconfig
[Sat Jan6 12:03:50 CET 2018] Using stage ACME_DIRECTORY: https://acme-staging-v02.api.letsencrypt.org/directory
[Sat Jan6 12:03:51 CET 2018] Registering account 
[Sat Jan6 12:03:52 CET 2018] Registered
[Sat Jan6 12:03:52 CET 2018] ACCOUNT_THUMBPRINT='xxx'
[Sat Jan6 12:03:52 CET 2018] Creating domain key 
[Sat Jan6 12:03:52 CET 2018] The domain key is here: /home/acme2/.acme.sh/roleplayer.org/roleplayer.org.key
[Sat Jan6 12:03:52 CET 2018] Multi domain='DNS:roleplayer.org,DNS:*.roleplayer.org'
[Sat Jan6 12:03:52 CET 2018] Getting domain auth token for each domain 
[Sat Jan6 12:03:53 CET 2018] Getting webroot for domain='roleplayer.org' 
[Sat Jan6 12:03:53 CET 2018] Getting webroot for domain='*.roleplayer.org' 
[Sat Jan6 12:03:53 CET 2018] Found domain api file: /home/acme2/.acme.sh/dnsapi/dns_ispconfig.sh 
[Sat Jan6 12:03:53 CET 2018] Getting Session ID
[Sat Jan6 12:03:53 CET 2018] Retrieved Session ID. 
[Sat Jan6 12:03:53 CET 2018] Getting Zoneinfo
[Sat Jan6 12:03:53 CET 2018] Retrieved zone data.
[Sat Jan6 12:03:54 CET 2018] Retrieved Server ID 
[Sat Jan6 12:03:54 CET 2018] Retrieved Zone ID 
[Sat Jan6 12:03:54 CET 2018] Retrieved Client ID.
[Sat Jan6 12:03:54 CET 2018] Added ACME Challenge TXT record to zone.
[Sat Jan6 12:03:54 CET 2018] Found domain api file: /home/acme2/.acme.sh/dnsapi/dns_ispconfig.sh 
[Sat Jan6 12:03:54 CET 2018] Getting Session ID
[Sat Jan6 12:03:54 CET 2018] Retrieved Session ID. 
[Sat Jan6 12:03:54 CET 2018] Getting Zoneinfo
[Sat Jan6 12:03:54 CET 2018] Retrieved zone data.
[Sat Jan6 12:03:54 CET 2018] Retrieved Server ID 
[Sat Jan6 12:03:54 CET 2018] Retrieved Zone ID 
[Sat Jan6 12:03:54 CET 2018] Retrieved Client ID.
[Sat Jan6 12:03:54 CET 2018] Added ACME Challenge TXT record to zone.
[Sat Jan6 12:03:54 CET 2018] Sleep 120 seconds for the txt records to take effect
[Sat Jan6 12:05:55 CET 2018] Verifying:roleplayer.org
[Sat Jan6 12:05:58 CET 2018] Success 
[Sat Jan6 12:05:58 CET 2018] Verifying:*.roleplayer.org
[Sat Jan6 12:06:01 CET 2018] Success 
[Sat Jan6 12:06:01 CET 2018] Getting Session ID
[Sat Jan6 12:06:01 CET 2018] Retrieved Session ID. 
[Sat Jan6 12:06:01 CET 2018] Retrieved Record ID.
[Sat Jan6 12:06:01 CET 2018] Removed ACME Challenge TXT record from zone.
[Sat Jan6 12:06:01 CET 2018] Getting Session ID
[Sat Jan6 12:06:01 CET 2018] Retrieved Session ID. 
[Sat Jan6 12:06:01 CET 2018] Retrieved Record ID.
[Sat Jan6 12:06:01 CET 2018] Removed ACME Challenge TXT record from zone.
[Sat Jan6 12:06:01 CET 2018] Verify finished, start to sign. 
[Sat Jan6 12:06:02 CET 2018] Cert success. 
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
[Sat Jan6 12:06:02 CET 2018] Your cert is in/home/acme2/.acme.sh/roleplayer.org/roleplayer.org.cer
[Sat Jan6 12:06:02 CET 2018] Your cert key is in/home/acme2/.acme.sh/roleplayer.org/roleplayer.org.key 
acme2@manager:~$ openssl x509 -text -noout -in .acme.sh/roleplayer.org/roleplayer.org.cer | grep DNS
                DNS:*.roleplayer.org, DNS:roleplayer.org
acme2@manager:~$
recolic commented 6 years ago

however issued certificate hasn't been trusted yet. screenshot

sjau commented 6 years ago

it's still staging...

tcocca commented 6 years ago

2 questions:

  1. Is DNS validation (_acme-challenge CNAME/TXT record) going to be the only supported verification method for wildcard certs? Is the value the same for the DNS record if you were to register both a 'domain.com' and a '*.domain.com' cert?
  2. Is the call to issue the cert for the wildcard going to require at least 2 hostnames with the first being non-wildcard? Or will the final version be able to issue just the wildcard cert for the domain?

Thanks, ~ Tom

sjau commented 6 years ago

tcocca:

See: https://github.com/Neilpang/acme.sh/issues/934#issuecomment-355740450

tcocca commented 6 years ago

@sjau Sorry I am unfamiliar with the dns_ispconfig, can you point me to a resource? Unfortunately the way our system will work we will not be controlling the domains at the registrar/nameservers. We just tell people to point their DNS records at our load balancer so I'm not sure if that will work for us or not.

Also, for my second question it looks like it will require a domain that is not a wildcard as the first domain and then a wildcard after that?

FernandoMiguel commented 6 years ago

if someone is pointing a cname/A record to your infra, I certainly would not want you to be able to issue a wildcard cert for my domain for that scenario, you will have to use HTTP01 or TLS01/02 for validation, and can't use acmev2 wildcard.

FernandoMiguel commented 6 years ago

Is the call to issue the cert for the wildcard going to require at least 2 hostnames with the first being non-wildcard?

no. the latest version of acme.sh already supports issuing wildcard certs with just the wildcard domain

tcocca commented 6 years ago

@FernandoMiguel Well they are pointing a wildcard to us as well because we create sub-domain websites for them as well (every person is getting a personal domain for their individual site).

For HTTP01/TLS01 then we wouldn't be able to do a wildcard right? We'd need to issue a cert for every subdomain site we are generating?

tcocca commented 6 years ago

@FernandoMiguel Thanks, I will check out the latest release. I think this is still in the "2" branch correct?

sjau commented 6 years ago

@tcocca

it's to show that you can just request a wildcard cert... you don't need to request another fqdn in there.

sjau commented 6 years ago

@tcocca only DNS-01 is supported for wildcards certs. Someone who can access domain.tld throught the web cannot necessarily also access mail.domain.tld. However one who can alter dns entries can point them where ever this person wants - so eglible for wildcard support.

Also .domain.tld isn't the same as .xxx.domain.tld. You'd have to request them both.

FernandoMiguel commented 6 years ago

if someone is pointing a wildcard subdomain to you, they would better transfer the NS zone of that subdomain.

ex: client APEX example.com

subdomain to point to your app blog.example.com and *.blog.example.com cname hosting.wedomagicblogs.io

could just be blog.example.com NS ns01.hosting.wedomagicblogs.io blog.example.com NS ns02.hosting.wedomagicblogs.io

that way you have full control of that zone, and you can then use LE DNS01 to validate that zone and issue a wildcard for *.blog.example.com , without the risk of issuing for bank.example.com

tcocca commented 6 years ago

Thats interesting for sure. Then for the main level we could use HTTP/TSL to register that domain.com/www.domain.com record. However, they want the subdomains at like johnsmith.domain.com not like johnsmith.blog.domain.com, so I'm not sure how the zone would work. I think we'd still need the top level zone in that case. I could have them add the _acme-challenge record but I'm still not sure I want to do that.

FernandoMiguel commented 6 years ago

for the APEX things become a bit more tricky but could always be a A record for those cases.... unless the client doesnt host anything else in the domain, than they could transfer the entire domain zone to you.

a potential alternative just suggested by @Neilpang is https://github.com/Neilpang/acme.sh/issues/1238

client would _acme-challenge.example.com CNAME _acme-challenge.hosting.wedomagicblogs.io and that would allow you to issue wildcards for the apex

sjau commented 6 years ago

But as we've seen since LE beta, for most cases individual certs for a single domain is fine enough. There's very little actual need for a wildcard cert IMHO - the biggest perceived need is lazyness :)

@tcocca If your clients point their DNS to you and administer the DNS through your server, you can offer wildcard support... or if they don't want to do that, just offer individual certs.

tcocca commented 6 years ago

@sjau well in this case we end up with some companies that have 500+ subdomain websites that we would need certs for, in some cases thousands, so we were going to go the wildcard route to manage that.

FernandoMiguel commented 6 years ago

you could say that when someone adds a new subdomain you could issue a new cert or update the SAN of the root cert. but that easily hits LE API rate limits. wildcards simplify those cases, if the cert is for one level only. more subdomains, more complex it gets.

of course you could run it on top of Cloudflare hosting-provider https://www.cloudflare.com/partners/hosting-provider/ or AWS ACM with Route 53 and not have to worry about LE limitations. and the cost is exactly the same