pax_global_header00006660000000000000000000000064150002466500014510gustar00rootroot0000000000000052 comment=7502af33b9eaf601feb93ba34868df4b7d55a9d3 acme.sh-0.0~git20250417.7502af3/000077500000000000000000000000001500024665000154025ustar00rootroot00000000000000acme.sh-0.0~git20250417.7502af3/Blogs-and-tutorials.md000066400000000000000000000226561500024665000215710ustar00rootroot00000000000000Here are some blogs that may help you: ## 中文 1. [使用 acme.sh 配置自动续签 SSL 证书](https://u.sb/acme-sh-ssl/) 1. [部署 使用 acme.sh 给 Nginx 安装 Let’ s Encrypt 提供的免费 SSL 证书](https://ruby-china.org/topics/31983) 1. [使用acme.sh快速搭建https](https://www.zoulei.net/2017/03/05/acme.sh_quick_start/) 1. [快速配置 HTTPS](https://blog.mynook.info/post/fast-way-to-configure-a-https-site) 1. https://www.rails365.net/articles/shi-yong-acme-sh-an-zhuang-let-s-encrypt-ti-gong-mian-fei-ssl-zheng-shu 1. [Windows Tomcat 配置Let’s Encrypt证书并自动更新](http://www.jianshu.com/p/80d72f34140b) 1. [acme.sh 自动更新 RSA、ECC 双证书实践](https://deepzz.com/post/acmesh-letsencrypt-cert-auto-renew.html) 1. https://hitian.info/notes/2017/02/16/acme-sh-create-letsencrypt-certificates-with-dns-api/ 1. https://nmchgx.com/acme-https/ 1. https://www.gubo.org/acme_sh-lets-encrypt-auto-signing-renewing-script/ 1. [让你的网站免费开启Https访问](https://rekkles.xyz/2017/07/05/create-a-https-website/) 1. https://github.com/Neilpang/acme.sh/wiki/%E8%AF%B4%E6%98%8E 1. https://www.gubo.org/acme_sh-lets-encrypt-auto-signing-renewing-script/ 1. https://www.prinice.org/2016/09/11/86/ 1. https://www.bfdz.ink/2016/11/08/28/ 1. https://yangac.me/41 1. https://opvps.com/letsencrypt-ssl/ 1. https://www.chdon.com/463.html 1. https://zhaochen.xyz/2016/06/21/5.html 1. https://www.logcg.com/archives/2007.html 1. https://guozeyu.com/2016/08/install-nginx-1-11-on-ubuntu/ 1. https://liliang13.com/tag/acme-sh/ 1. https://meta.discoursecn.org/t/topic/1061 1. https://mechanus.io/acme-sh-ji-li-tui-jian-de-lets-encrypt-gong-ju/ 1. https://blog.messyidea.com/archives/42/ 1. [使用le.sh脚本通过CloudFlare API获取DNS TXT记录来签发站点证书](https://bismarck.moe/2016/02/07/%E4%BD%BF%E7%94%A8le-sh%E8%84%9A%E6%9C%AC%E9%80%9A%E8%BF%87cloudflare-api%E8%8E%B7%E5%8F%96dns-txt%E8%AE%B0%E5%BD%95%E6%9D%A5%E7%AD%BE%E5%8F%91%E7%AB%99%E7%82%B9%E8%AF%81%E4%B9%A6/) 1. http://blog.topspeedsnail.com/archives/3823 1. https://www.niefufeng.com/articles/letsencrypt-certificate 1. https://www.ershiwo.com/2016/03/use-lets-encrypt-on-multi-servers.html 1. http://frankwei.xyz/kuai-su-ban-fa-ge-mian-fei-de-sslzheng-shu/ 1. http://www.yilan.io/article/5703d07dc41b4c012e973bcb 1. https://yatesun.com/2016/04/lets-encrypt-certificate/ 1. https://simiki.xulog.com/linux/issue%20and%20install%20cert.html 1. https://zhangly.com/use-acme-sh/ 1. https://www.nanqinlang.com/shell-acme.html 1. https://b.tossp.com/2018/在docker中申请lets-encrypt通配符https证书/ ## English 1. [FreeBSD.org switched to acme.sh](https://blog.crashed.org/letsencrypt-in-freebsd-org/) 1. [Install your Let’s Encrypt SSL certificate with acme.sh](https://kb.virtubox.net/knowledgebase/install-lets-encrypt-ssl-certificate-acme-sh/) 1. https://retifrav.github.io/blog/2021/04/05/acme-sh-instead-of-certbot/ 1. https://east.fm/posts/a-bash-client-for-the-acme-protocol/index.html 1. https://east.fm/posts/acme-sh-cpanel-a2hosting/index.html 1. https://kazoo.ga/kazoo-it-speaks-https/ 1. https://tryingtobeawesome.com/encryptdaddy/ 1. [Let's Encrypt certificates on Synology DSM 5](http://blog.raorn.name/2017/02/lets-encrypt-certificates-on-synology.html) 1. http://centosquestions.com/setup-solusvm-with-lets-encrypt-free-ssl-certificate/ 1. http://blog.e-zest.com/ssl-encryption-using-lets-encrypt-on-aws-ec2-amazon-linux 1. https://odd-one-out.serek.eu/lets-encrypt-dns-challenge-cloudflare-acme-sh/ 1. http://biowikifarm.net/meta/HTTPS_Support_via_Let%E2%80%99s_Encrypt 1. https://medium.com/@pavlakis/using-acme-sh-to-generate-letsencrypt-certificates-c98f28752e9f 1. https://lttviet.com/2016/09/13/letsencrypt/ 1. [HTTPS on WebFaction using Let's Encrypt](https://blog.rarepebble.com/https-on-webfaction/) 1. https://lttviet.com/2016/09/13/letsencrypt/ 1. https://unix.stackexchange.com/questions/327125/letencrypt-on-shared-hosting-neither-yum-or-dnf-found 1. https://mijndertstuij.nl/writing/posts/using-acme.sh-to-issue-lets-encrypt-certificates/ 1. https://forums.zimbra.org/viewtopic.php?t=60781 1. https://www.ollegustafsson.com/en/letsencrypt-routeros/ 1. https://kralik.io/2016/11/26/how-easy-is-to-use-https-with-lets-encrypt-and-acme-sh/ 1. https://www.juliogonzalez.es/lets-encrypt-ssl-certificates-at-cpanel-without-native-support-for-example-at-namecheap/352 1. https://www.rmedgar.com/blog/using-acme-sh-with-nginx 1. https://yulinling.net/post/lets_encrypt_on_host_without_root_access/ 1. https://erdees.ru/it/all-about-let-s-encrypt/ 1. https://pve.proxmox.com/wiki/HTTPSCertificateConfiguration 1. https://forum.openwrt.org/viewtopic.php?pid=327103#p327103 1. https://got-tty.org/lets-encrypt-in-pfsense 1. https://community.webfaction.com/questions/19988/using-letsencrypt 1. https://www.loadbalancer.org/blog/loadbalancer-org-with-lets-encrypt-quick-and-dirty 1. https://blog.quiptiq.com/2016/05/05/installing-a-lets-encrypt-certificate-for-znc/ 1. https://www.arowan.be/2016/04/18/certificat-lets-encrypt-sur-votre-hyperviseur-proxmox-update/ 1. https://chevereto.com/community/threads/tutorial-free-ssl-from-letsencrypt-setup-for-nginx-1-9-x.7217/ 1. http://www.mcpressonline.com/security/techtip-let-s-encrypt-together.html 1. https://meta.discourse.org/t/setting-up-lets-encrypt/40709 1. http://www.cyberciti.biz/faq/how-to-configure-nginx-with-free-lets-encrypt-ssl-certificate-on-debian-or-ubuntu-linux/ 1. https://www.cyberciti.biz/faq/how-to-configure-lighttpd-web-server-with-free-lets-encrypt-ssl-certificate-on-debian-or-ubuntu-linux/ 1. https://cpbotha.net/2016/07/18/installing-free-lets-encrypt-ssl-certificates-on-webfaction-in-3-easy-steps/ 1. http://www.ecsoft2.org/howto/using-let%E2%80%99s-encrypt-os2 1. https://ramy.nl/2016/03/23/installing-lets-encrypt-on-ubuntu-14-04/ 1. https://www.naschenweng.info/2017/01/06/securing-ubiquiti-unifi-cloud-key-encrypt-automatic-dns-01-challenge/ 1. https://www.naschenweng.info/2017/01/06/automatic-ssl-renewal-encrypt-dsm-5-x-synology-ds1010-dns-01-verification/ 1. http://community.brocade.com/t5/vADC-Blog/Using-Let-s-Encrypt-certificates-with-Brocade-vADC/ba-p/90491 1. https://blog.artooro.com/2017/02/16/quick-easy-lets-encrypt-setup-on-pfsense-using-acme/ 1. https://thedevops.party/lets-encrypt-ssl-certificate-on-pfsense-2-3/ 1. http://126kr.com/article/846xm2nb9sy 1. https://forge.puppet.com/fraenki/acme/1.0.0 1. https://forums.novell.com/showthread.php/502375-LetsEncrypt-setup 1. https://www.imagescape.com/blog/2017/04/25/lets-encrypt-alternative-acme-client/ 1. https://wiki.nps.edu/display/~mcgredo/letsencrypt 1. http://icebearsoft.euweb.cz/letsencrypt-howto/#d1e970 1. [Free Wildcard Certificates using Azure DNS, Let’s Encrypt and acme.sh](https://noobient.com/post/172797046216/free-wildcard-certificates-using-azure-dns-lets) 1. [How to use acme.sh to install and update your VMware vCenter and PSC servers](https://wiki.9r.com.au/display/9R/LetsEncrypt+Certificates+for+vCenter+and+PSC) 1. [Install a SSL reverse proxy on an Asus Router with OVH domain](https://github.com/pedrom34/TutoAsus/) 1. [How to use the Edgenexus Cert manager to deploy ACME certs](https://www.edgenexus.io/docs/guides/app-user-guides/Edgnexus%20EdgeCert%20Manager/EN/html/get_and_install_the_edgenexus_ssl_certificate_manager_.htm) 1. [acme.sh with HAProxy integration](https://github.com/haproxy/wiki/wiki/Letsencrypt-integration-with-HAProxy-and-acme.sh) 1. [Trusted TLS certificates for internal use](https://blog.mni.li/posts/internal-tls-with-caddy/) ## French 1. https://notes.ailothaen.fr/post/2017/01/Mise-en-place-de-HTTPS-sur-Apache-avec-Let-s-Encrypt 1. https://howto.biapy.com/fr/debian-gnu-linux/systeme/logiciels/installer-le-client-certbot-lets-encrypt-acme-sh-sur-debian 1. https://www.thelinuxfr.org/lets-encrypt-acme-sh-debian-nginx/ 1. https://jereze.com/fr/snippets/letsencrypt-acme-no-root 1. https://kb.virtubox.net/fr/knowledgebase/obtenir-installer-certificat-ssl-wildcard-acme-sh-nginx/ 1. [Installer un reverse proxy SSL sur un routeur Asus avec un nom de domaine Ovh](https://github.com/pedrom34/TutoAsus/blob/master/Readme.fr.md) 1. [Certificat Let’s Encrypt sur Azure Container Instances et NGINX](https://r3dlin3.github.io/2020/01/30/aci-letsencrypt-nginx/) ## Russian 1. http://wpb.1gb.ru/2016/08/27/%D1%83%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0-https-%D0%B4%D0%BB%D1%8F-%D1%81%D0%B0%D0%B9%D1%82%D0%B0-letsencrypt-ssl-%D1%81%D0%B5%D1%80%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%82-nginx-debian/ ## Polish 1. https://holas.pl/2016/02/24/zabezpiecz-swoja-strone-www-za-darmo-certyfikatem-ssl-od-lets-encrypt/ ## Indonesian 1. [Cara memasang ZeroSSL + Renew Otomatis di Netlify, BunnyCDN, cPanel dan DirectAdmin (pakai acme.sh)](https://farrel.franqois.id/cara-memasang-zerossl-di-netlify-bunnycdn-cpanel-directadmin/) ## Italian 1. https://kb.kurgan.org/LetsEncrypt ## Japanese 1. https://http2.try-and-test.net/acme_sh.html 1. http://qiita.com/fujiba/items/249e8cb0484d5bbc5b21 1. http://d.hatena.ne.jp/worris2/20160213/1455375785 ## Czech 1. https://www.root.cz/clanky/acme-sh-snadna-cesta-k-certifikatu-od-let-s-encrypt/ 1. https://havel.mojeservery.cz/lets-encrypt-snadno-s-acmesh/ 1. https://www.strachota.net/category/bezpecnost ## German 1. http://adminforge.de/webserver/lets-encrypt-via-acme-sh-fuer-apache-und-nginx/ 1. https://blog.sengotta.net/lets-encrypt-dns-validation-mit-ovh-domain-nutzen/ 1. http://blog.antiblau.de/2016/10/21/letsencrypt-mit-acme-sh-und-lighttpd/ ## Spanish 1. http://sinanimodelucro.net/lang/en/2016/07/10/acme-sh-facil-no-tanto-en-centos-5/ acme.sh-0.0~git20250417.7502af3/BuyPass.com-CA.md000066400000000000000000000241451500024665000203560ustar00rootroot00000000000000See https://github.com/Neilpang/acme.sh/pull/1989 Thanks to [www.buypass.com](https://www.buypass.com/) > Buypass Go SSL is the name of the SSL certificate you will obtain from Buypass CA using the Buypass ACME API. This is a Domain Validated (DV) certificate. > > Advantages > > * free certificate > * automatic issuance and renewal of certificates - no user action required > * certificate lifetime is 180 days > * certificate from a Norwegian publicly trusted CA > * trusted by all major browser vendors https://www.buypass.com/ssl/resources/go-ssl-technical-specification https://community.buypass.com/t/63d4ay/buypass-go-ssl-endpoints **Production:** https://api.buypass.com/acme/directory **Test environment:** https://api.test4.buypass.no/acme/directory Usage: First time register account with an email, the mail is required by buypass.com ```sh acme.sh --server https://api.buypass.com/acme/directory \ --register-account --accountemail me@example.com ``` Then you can issue cert now. ```sh acme.sh --server https://api.buypass.com/acme/directory \ --issue -d example.com -d www.example.com ..... \ --days 170 ``` Since buypass cert has 180 days lifetime, so we specify `--days 170` for acme.sh to renew the cert at the 170 th day. If you don't specify days, it will renew at 60 days by default. Once issued, you can renew the cert without `--server` parameter. ```sh acme.sh --renew -d example.com ``` Don't worry, all the certs will be automatically renewed as usual. ---------------------- 1. BuyPass supports both v1 and v2 no wildcard cert, but you can add up to 5 domains per cert. 2. It has 180 days lifetime. 3. ECC cert is supported, but the signing root is a RSA root. Example: ``` -----BEGIN CERTIFICATE----- MIIGbDCCBFSgAwIBAgIKCRFsFobOdP0VfTANBgkqhkiG9w0BAQsFADBLMQswCQYD VQQGEwJOTzEdMBsGA1UECgwUQnV5cGFzcyBBUy05ODMxNjMzMjcxHTAbBgNVBAMM FEJ1eXBhc3MgQ2xhc3MgMiBDQSA1MB4XDTE4MTIyOTAxMzIyNVoXDTE5MDYyNzIx NTkwMFowGjEYMBYGA1UEAwwPYnV5cGFzcy5hY21lLnNoMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA0H5zERFpOG5en3JRnIZ6LXxDohtID0IbsdK2vjla ARwuClpJzfcRd0iWZtsV0sUy4zlNv0CZEvwxM1egpL1cEpfrDzMOjpy7OmSyBiEV Y6KxhBr/UNdYWZNaoWEQyHTaaYsEyoMTIL8Wt7uqnoxrVHrY4goYiJTqk8Xk8Skj 3QSLSb/jkLFfCl7gdAbgylXKhq8id5gp7VUnCUB5cp7wq1n6GCbn2k4HRzKLNXT2 4AZm/a+nNbhA6hBRm79hl2lvtefYM7wB+LbDODLT3AxabT3fjHPprAtcZ296H+gG +w11urMCOtgADU9jgLikXkQNPQ1ZffbANs5+lN5MAwyNYwIDAQABo4ICgTCCAn0w CQYDVR0TBAIwADAfBgNVHSMEGDAWgBQnUqRvLSqrQJOQ7NZpy/58YTt8QjAdBgNV HQ4EFgQUYtkEq1qyZWbHkD5GhIhHxqALb+8wDgYDVR0PAQH/BAQDAgWgMB0GA1Ud JQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAfBgNVHSAEGDAWMAoGCGCEQgEaAQIH MAgGBmeBDAECATA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmJ1eXBhc3Mu bm8vY3JsL0JQQ2xhc3MyQ0E1LmNybDAvBgNVHREEKDAmgg9idXlwYXNzLmFjbWUu c2iCE3d3dy5idXlwYXNzLmFjbWUuc2gwagYIKwYBBQUHAQEEXjBcMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5idXlwYXNzLmNvbTA1BggrBgEFBQcwAoYpaHR0cDov L2NydC5idXlwYXNzLm5vL2NydC9CUENsYXNzMkNBNS5jZXIwggEFBgorBgEEAdZ5 AgQCBIH2BIHzAPEAdgC72d+8H4pxtZOUI5eqkntHOFeVCqtS6BqQlmQ2jh7RhQAA AWf3l0qaAAAEAwBHMEUCICYVuYUQuwAqgWv0dlM/p6+nbHOkrod/t+US2Qua1Ybw AiEA8YS0Nh/N7opKZF4p8g3vaICQG2g/Y8uqKUuTA3Dz1IIAdwBVgdTCFpA2AUrq C5tXPFPwwOQ4eHAlCBcvo6odBxPTDAAAAWf3l0vpAAAEAwBIMEYCIQDyRw4nBKTF qIVL8NX7vROojrXu4wpeRjx2PGsPKFl4fwIhAJyE9KedaBY7QP/YQp1JKm9gXw64 2KSv3vizaM1xSQ2DMA0GCSqGSIb3DQEBCwUAA4ICAQCMUUgNvRZrUBF0yZD1MKvd aJ7UuGqisfuJroDhFHNFWqhahIPr3kFOA1YWTZdg/8xlnkfwZ5Q4qoC9U4y08Iy7 +nyzSHohDg1uH16JiuLyh1I/aq34wDWGEzRAKHL3FGRQYE8+xk3xT5lzVjZpuc07 sxjez02Mbd5UbrflRXjT+l0KAC2kUrZ1CI8CjHdmA74RL3GRIL/hZaWBDTp64xr/ QKJqXUKZdUIY2CGUTDKKF/RVdLqHle3wF2u0Hog/10HwlTf/KRmohPdD4XPGrU1Y PKSfP5HGIhAPOSAbpyeR0wN0GAR84VNF2PVgttqtJCAqVLfs8dscMDce4Yujrg4a i+aTB5pPb0fm+wa+z6kwFtu8Aauag9jN7bAw13dq6VpiLxVCPBa1mmMgjJCj5Abl rcV5itofkhz1E/ZVTH+k2KzBICqE2DZkxLVGEuhY9k6RuicY6FWZ83eIZKx3Dmci 2FBnNob0b1jvC79lo3eyDB6G8+dFs29l8RvrNLdxiZlidLJdjbcEQd+OZ3ZWlVS7 cwQ3G6VZh1+8limcZechXCa/aonf2JyadWfCxZRZRJsy1NMLT7yd3w6haubgZ0f2 a96zwu5nXXQ7xbawEajLy6Qll9yejmKSVUVoyTH1AoZoaA/NOnjnQXveeiktArlg 86H+f+G4O5uuktiHIeAYNg== -----END CERTIFICATE----- ``` ``` Certificate: Data: Version: 3 (0x2) Serial Number: 09:11:6c:16:86:ce:74:fd:15:7d Signature Algorithm: sha256WithRSAEncryption Issuer: C = NO, O = Buypass AS-983163327, CN = Buypass Class 2 CA 5 Validity Not Before: Dec 29 01:32:25 2018 GMT Not After : Jun 27 21:59:00 2019 GMT Subject: CN = buypass.acme.sh Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:d0:7e:73:11:11:69:38:6e:5e:9f:72:51:9c:86: 7a:2d:7c:43:a2:1b:48:0f:42:1b:b1:d2:b6:be:39: 5a:01:1c:2e:0a:5a:49:cd:f7:11:77:48:96:66:db: 15:d2:c5:32:e3:39:4d:bf:40:99:12:fc:31:33:57: a0:a4:bd:5c:12:97:eb:0f:33:0e:8e:9c:bb:3a:64: b2:06:21:15:63:a2:b1:84:1a:ff:50:d7:58:59:93: 5a:a1:61:10:c8:74:da:69:8b:04:ca:83:13:20:bf: 16:b7:bb:aa:9e:8c:6b:54:7a:d8:e2:0a:18:88:94: ea:93:c5:e4:f1:29:23:dd:04:8b:49:bf:e3:90:b1: 5f:0a:5e:e0:74:06:e0:ca:55:ca:86:af:22:77:98: 29:ed:55:27:09:40:79:72:9e:f0:ab:59:fa:18:26: e7:da:4e:07:47:32:8b:35:74:f6:e0:06:66:fd:af: a7:35:b8:40:ea:10:51:9b:bf:61:97:69:6f:b5:e7: d8:33:bc:01:f8:b6:c3:38:32:d3:dc:0c:5a:6d:3d: df:8c:73:e9:ac:0b:5c:67:6f:7a:1f:e8:06:fb:0d: 75:ba:b3:02:3a:d8:00:0d:4f:63:80:b8:a4:5e:44: 0d:3d:0d:59:7d:f6:c0:36:ce:7e:94:de:4c:03:0c: 8d:63 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Authority Key Identifier: keyid:27:52:A4:6F:2D:2A:AB:40:93:90:EC:D6:69:CB:FE:7C:61:3B:7C:42 X509v3 Subject Key Identifier: 62:D9:04:AB:5A:B2:65:66:C7:90:3E:46:84:88:47:C6:A0:0B:6F:EF X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Certificate Policies: Policy: 2.16.578.1.26.1.2.7 Policy: 2.23.140.1.2.1 X509v3 CRL Distribution Points: Full Name: URI:http://crl.buypass.no/crl/BPClass2CA5.crl X509v3 Subject Alternative Name: DNS:buypass.acme.sh, DNS:www.buypass.acme.sh Authority Information Access: OCSP - URI:http://ocsp.buypass.com CA Issuers - URI:http://crt.buypass.no/crt/BPClass2CA5.cer CT Precertificate SCTs: Signed Certificate Timestamp: Version : v1 (0x0) Log ID : BB:D9:DF:BC:1F:8A:71:B5:93:94:23:97:AA:92:7B:47: 38:57:95:0A:AB:52:E8:1A:90:96:64:36:8E:1E:D1:85 Timestamp : Dec 29 01:32:26.650 2018 GMT Extensions: none Signature : ecdsa-with-SHA256 30:45:02:20:26:15:B9:85:10:BB:00:2A:81:6B:F4:76: 53:3F:A7:AF:A7:6C:73:A4:AE:87:7F:B7:E5:12:D9:0B: 9A:D5:86:F0:02:21:00:F1:84:B4:36:1F:CD:EE:8A:4A: 64:5E:29:F2:0D:EF:68:80:90:1B:68:3F:63:CB:AA:29: 4B:93:03:70:F3:D4:82 Signed Certificate Timestamp: Version : v1 (0x0) Log ID : 55:81:D4:C2:16:90:36:01:4A:EA:0B:9B:57:3C:53:F0: C0:E4:38:78:70:25:08:17:2F:A3:AA:1D:07:13:D3:0C Timestamp : Dec 29 01:32:26.985 2018 GMT Extensions: none Signature : ecdsa-with-SHA256 30:46:02:21:00:F2:47:0E:27:04:A4:C5:A8:85:4B:F0: D5:FB:BD:13:A8:8E:B5:EE:E3:0A:5E:46:3C:76:3C:6B: 0F:28:59:78:7F:02:21:00:9C:84:F4:A7:9D:68:16:3B: 40:FF:D8:42:9D:49:2A:6F:60:5F:0E:B8:D8:A4:AF:DE: F8:B3:68:CD:71:49:0D:83 Signature Algorithm: sha256WithRSAEncryption 8c:51:48:0d:bd:16:6b:50:11:74:c9:90:f5:30:ab:dd:68:9e: d4:b8:6a:a2:b1:fb:89:ae:80:e1:14:73:45:5a:a8:5a:84:83: eb:de:41:4e:03:56:16:4d:97:60:ff:cc:65:9e:47:f0:67:94: 38:aa:80:bd:53:8c:b4:f0:8c:bb:fa:7c:b3:48:7a:21:0e:0d: 6e:1f:5e:89:8a:e2:f2:87:52:3f:6a:ad:f8:c0:35:86:13:34: 40:28:72:f7:14:64:50:60:4f:3e:c6:4d:f1:4f:99:73:56:36: 69:b9:cd:3b:b3:18:de:cf:4d:8c:6d:de:54:6e:b7:e5:45:78: d3:fa:5d:0a:00:2d:a4:52:b6:75:08:8f:02:8c:77:66:03:be: 11:2f:71:91:20:bf:e1:65:a5:81:0d:3a:7a:e3:1a:ff:40:a2: 6a:5d:42:99:75:42:18:d8:21:94:4c:32:8a:17:f4:55:74:ba: 87:95:ed:f0:17:6b:b4:1e:88:3f:d7:41:f0:95:37:ff:29:19: a8:84:f7:43:e1:73:c6:ad:4d:58:3c:a4:9f:3f:91:c6:22:10: 0f:39:20:1b:a7:27:91:d3:03:74:18:04:7c:e1:53:45:d8:f5: 60:b6:da:ad:24:20:2a:54:b7:ec:f1:db:1c:30:37:1e:e1:8b: a3:ae:0e:1a:8b:e6:93:07:9a:4f:6f:47:e6:fb:06:be:cf:a9: 30:16:db:bc:01:ab:9a:83:d8:cd:ed:b0:30:d7:77:6a:e9:5a: 62:2f:15:42:3c:16:b5:9a:63:20:8c:90:a3:e4:06:e5:ad:c5: 79:8a:da:1f:92:1c:f5:13:f6:55:4c:7f:a4:d8:ac:c1:20:2a: 84:d8:36:64:c4:b5:46:12:e8:58:f6:4e:91:ba:27:18:e8:55: 99:f3:77:88:64:ac:77:0e:67:22:d8:50:67:36:86:f4:6f:58: ef:0b:bf:65:a3:77:b2:0c:1e:86:f3:e7:45:b3:6f:65:f1:1b: eb:34:b7:71:89:99:62:74:b2:5d:8d:b7:04:41:df:8e:67:76: 56:95:54:bb:73:04:37:1b:a5:59:87:5f:bc:96:29:9c:65:e7: 21:5c:26:bf:6a:89:df:d8:9c:9a:75:67:c2:c5:94:59:44:9b: 32:d4:d3:0b:4f:bc:9d:df:0e:a1:6a:e6:e0:67:47:f6:6b:de: b3:c2:ee:67:5d:74:3b:c5:b6:b0:11:a8:cb:cb:a4:25:97:dc: 9e:8e:62:92:55:45:68:c9:31:f5:02:86:68:68:0f:cd:3a:78: e7:41:7b:de:7a:29:2d:02:b9:60:f3:a1:fe:7f:e1:b8:3b:9b: ae:92:d8:87:21:e0:18:36 ```acme.sh-0.0~git20250417.7502af3/CA.md000066400000000000000000000021231500024665000162050ustar00rootroot00000000000000Comparison of the features offered for free by the supported CAs: | CA | MaxLifetime | ECC Chain | Domain Count | Wildcard | IPv4 | IPv6 | NotBefore | NotAfter | IDN | Test Server | |---------------|-------------|-----------|--------------|----------|---- |------|-------------|----------|-------|---------------| | Let's Encrypt | 90 | Full | 100 | Yes | No | No | No | No | Yes | Yes | | ZeroSSL | 90 | Full | 100 | Yes | No | No | Yes (+1d) | Yes | Yes | No | | Google | 90 | Partial | 100 | Yes | No | No | No | Yes | No | Yes | | Buypass | 180 | Partial | 5 | No | No | No | No | No | Yes | Yes | | SSL.com | 104 | Partial | 2 | No | No | No | No | No | Yes | No | Details for CAs servers are available here: [Server](https://github.com/acmesh-official/acme.sh/wiki/Server)acme.sh-0.0~git20250417.7502af3/Change-default-CA-to-ZeroSSL.md000066400000000000000000000046121500024665000227360ustar00rootroot00000000000000Previously, if no `server` was provided, or if don't have `--set-default-ca` set, acme.sh used letsencrypt as the default CA. https://github.com/acmesh-official/acme.sh/wiki/Server As of acme.sh v3.0, the default CA is now [ZeroSSL](https://github.com/acmesh-official/acme.sh/wiki/ZeroSSL.com-CA). This change will only affect the newly created(issued) certs after `August-1st` (with v3.0), any pre-existing certs will still be renewed automatically against the current CA. Q&A: 1. As an existing user, what do I need to do? Generally, nothing needs to do. (If auto-upgrade is enabled, acme.sh can upgrade itself). No matter acme.sh is upgraded to v3.0 or not, your existing certs will be renewed as before, against the same CA it's currently using. 2. Will I still be able to use letsencrypt then? Yes, of course. You are still free to use any supported CA with providing `--server` parameter. ``` acme.sh --issue -d example.com --dns dns_cf --server letsencrypt ``` 3. What if I don't like this change? I want to stick to letsencrypt? Yes, sure. You can `--set-default-ca` now or any time you like. Then acme.sh will always use the default ca you set: ``` acme.sh --set-default-ca --server letsencrypt ``` If you set the default CA, acme.sh will respect your choice first. It will always use this default ca in the future, no matter in `v2.*`, `v3.*` or any future `v4.*`. **acme.sh always respects your choice first, and will never make any changes to your files without your permissions.** 4. My current cert is using letsencrypt, Will it be changed when renewed then? No, and never. Don't worry. when your cert is renewed, it will use the current CA, not the default CA. 5. As a new user after `August-1st 2021`(v3.0), what will it look like to me? You can install acme.sh as normal, nothing is changed. You can also issue certs as normal [See how to issue a cert](https://github.com/acmesh-official/acme.sh/wiki/How-to-issue-a-cert): ``` acme.sh --issue -d example.com --dns dns_cf ``` The cert will be issued with the default CA [ZeroSSL](https://github.com/acmesh-official/acme.sh/wiki/ZeroSSL.com-CA) You can also try with letsencrypt: ``` acme.sh --issue -d example.com --dns dns_cf --server letsencrypt ``` There is a comparison: ZeroSSL vs Let's Encrypt: https://zerossl.com/letsencrypt-alternative/ acme.sh-0.0~git20250417.7502af3/Code-of-conduct.md000066400000000000000000000040471500024665000206420ustar00rootroot00000000000000# Common rules for contributing to acme.sh ### 1. The file shebang must be `sh` not `bash` acme.sh is a `unix shell` script, not just a `bash` script. If you want to contribute your script, the shebang must be: ```sh #!/usr/bin/env sh ``` After the installation, acme.sh could change the shebang to bash to get better performance if you have bash on your machine. Of course, if you just use it on your own, it can be any valid shebang on your machine. It could be `sh` or `bash`, it's up to you. ### 2. Please create a new issue for future bugs Please report a new issue here: `" Report bugs to xxxx dns api"` https://github.com/Neilpang/acme.sh/issues And please watch to that issue. Any future bug will be reported there. Example: https://github.com/Neilpang/acme.sh/issues/2057 ### 3. Cross-Platform Compatibility Guide 1. Don't use `grep -o` options, please use `_egrep_o()` function instead, other grep options may be used with caution. 2. Don't use `curl` or `wget`, please use `_get()` or `_post()` function instead. The `_post()` function can send `POST`, `PUT` or `UPDATE` requests. 3. Do not use `sed -e`, which causes a problem in OS X and BSD. 4. Do not use `sed` with labels, which causes `Label too long` problem in Solaris. 5. Do not use `sed` with newlines (`\n`), which causes a problem in OS X and BSD. 6. Do not use `grep -E` option. If you need a BSD or Solaris development environment, please head to [vmactions](https://github.com/vmactions). For example, you can use [solaris-shell](https://github.com/vmactions/shell-solaris) to get a shell environment in Solaris. ## Style Guidelines acme.sh uses shellcheck for new commits and also enforces style guidelines. To avoid the most common travis failures: * Use indentation with 2 spaces * remove trailing spaces * Doublequote variables (use _debug txtvalue "$txtvalue" instead of _debug txtvalue=$txtvalue) * Always check the travis results after a commit * Consider using shellcheck (https://www.shellcheck.net/) before commiting * `shfmt -l -w -i 2 .` will re-indent your files acme.sh-0.0~git20250417.7502af3/DNS-API-Dev-Guide.md000066400000000000000000000231561500024665000205350ustar00rootroot00000000000000# Guide for developing a DNS API for acme.sh This guide is to help any developer interested to build a brand new DNS API for acme.sh ## Some useful tips 1. It's normal to run into errors, so do use `--debug 2` when testing. For e.g., `acme.sh --issue --debug 2 -d example.com --dns dns_myapi` 2. It's normal to burst rate limits for Let's Encrypt, so do use `--staging` when testing. For e.g., `acme.sh --issue --staging --debug 2 -d example.com --dns dns_myapi` Read [issue 1787](https://github.com/acmesh-official/acme.sh/issues/1787) for details. Remember to remove `--staging` after testing. 3. It's normal that the dns script is not run if the domain was validated before. Forcing execution of the DNS API script can be achieved by clearing the "valid" status of a domain at Let’s Encrypt via the `--deactivate` command. Wildcard domains have their own status, so these have to be deactivated separately. ``` acme.sh --deactivate [--server letsencrypt_test] -d 'test.example.com' -d '*.test.example.com' ``` Let's assume your API name is `myapi`, and you will use your API like: ```sh export MYAPI_Username=myname export MYAPI_Password=mypass acme.sh --issue -d example.com --dns dns_myapi ``` Here we go: ### 1. The Cloudflare DNS API is a recommended reference: Read it first: https://github.com/acmesh-official/acme.sh/blob/master/dnsapi/dns_cf.sh ### 2. The script file name must be `dns_myapi.sh` The file name must be in this format: `dns_yourApiName.sh`, in this example, it should be `dns_myapi.sh` ### 3. The file can be placed in `acme.sh/` folder, or in `acme.sh/dnsapi/` subfolder. If you want to contribute your script to `acme.sh` project, it must be placed in `acme.sh/dnsapi/` folder. If you just want to use your script on your machine, you can put it in `.acme.sh/` or `.acme.sh/dnsapi/` folders. acme.sh searches the script files in either the acme.sh home dir(`.acme.sh/`) or in the `dnsapi` subfolder(`.acme.sh/dnsapi`). ### 4. There must be 2 functions in your script: ```sh # Usage: add _acme-challenge.www.domain.com "XKrxpRBosdIKFzxW_CT3KLZNf6q0HG9i01zxXp5CPBs" # Used to add txt record dns_myapi_add() { } # Usage: fulldomain txtvalue # Used to remove the txt record after validation dns_myapi_rm() { } ``` Actually, the `dns_myapi_add()` is required, but `dns_myapi_rm()` is optional. You can just write the add function at the beginning for testing purposes, it's `highly recommended` to implement the rm function too. Otherwise, your TXT records will increase 1 every 2 months. ### 5. Guide for the add function Steps when you write the `dns_myapi_add()` function: #### 1. Get the full domain and the txt record: ```sh dns_myapi_add() { fulldomain=$1 txtvalue=$2 ... } ``` #### 2. You must save your username and password in the add function: The credentials such as username, password, API key or API token etc, must be saved so that acme.sh can renew the cert automatically in future. It will reuse the credentials automatically. ```sh dns_myapi_add() { ... MYAPI_Username="${MYAPI_Username:-$(_readaccountconf_mutable MYAPI_Username)}" MYAPI_Password="${MYAPI_Password:-$(_readaccountconf_mutable MYAPI_Password)}" if [ -z "$MYAPI_Username" ] || [ -z "$MYAPI_Password" ]; then MYAPI_Username="" MYAPI_Password="" _err "You don't specify cloudflare api key and email yet." _err "Please create your key and try again." return 1 fi #save the credentials to the account conf file. _saveaccountconf_mutable MYAPI_Username "$MYAPI_Username" _saveaccountconf_mutable MYAPI_Password "$MYAPI_Password" ... } ``` #### 3. Detect which part is your root zone. The full domain could be in either one of the following formats: 1. `_acme-challenge.www.example.com` 2. `_acme-challenge.example.com` 3. `_acme-challenge.example.co.uk` 4. `_acme-challenge.www.example.co.uk` 5. `_acme-challenge.sub1.sub2.www.example.co.uk` 6. `sub1.sub2.example.co.uk` 7. `example.com` (For [DNS alias mode](https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode)) 8. `example.co.uk` (For [DNS alias mode](https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode)) For most of the DNS providers, you must determine which part is the domain root zone(example.com or example.co.uk), and which part is the subdomain(_acme-challenge or _acme-challenge.www) *You can not just split the full domain, and get the first part as a subdomain, and the rest as root zone. Please make sure you can handle all the formats above.* A good practice is to list all your root zones through your DNS API, then compare and detect which part is the root zone. Then the rest is the subdomain. See: https://github.com/acmesh-official/acme.sh/blob/master/dnsapi/dns_cf.sh#L142 ```sh dns_myapi_add() { ... _debug "First detect the root zone" if ! _get_root "$fulldomain"; then _err "invalid domain" return 1 fi ... ``` #### 4. Call your DNS API to add a TXT record. Most of the DNS providers provide an HTTP API or REST API. So, you can just use the HTTP GET/POST/PUT/DELETE method to call their API to add/remove the TXT record. acme.sh defined two functions to make http GET/POST/PUT/DELETE connections. See: - https://github.com/acmesh-official/acme.sh/blob/8ded524236347d5a1f7a3169809cab9cf363a1c8/acme.sh#L2013 - https://github.com/acmesh-official/acme.sh/blob/8ded524236347d5a1f7a3169809cab9cf363a1c8/acme.sh#L1887 ``` _get() {} _post() {} ``` You can use them directly. Please take care that the `_post()` function can send POST/PUT/DELETE requests, not just `POST`. See: - https://github.com/acmesh-official/acme.sh/blob/975a7359a23cd5f8335aca58ceab552d8d967ea7/dnsapi/dns_infoblox.sh#L85 - https://github.com/acmesh-official/acme.sh/blob/ded7a5438ce94c4dd0435068de5c0c384b60e4dd/dnsapi/dns_cf.sh#L73 Do not use `curl` or `wget` directly in your script. **Note:** Wildcard certificates require two TXT values. When implementing the method make sure that you append the value instead of replacing it dig -t txt _acme-challenge.example.com should return ``` ; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t txt _acme-challenge.example.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35476 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;_acme-challenge.example.com. IN TXT ;; ANSWER SECTION: _acme-challenge.example.com. 3600 IN TXT "tye6yGOxJEffnXDzZKNJjOHSsCFtKwU_5L0ykmY8CzE" _acme-challenge.example.com. 3600 IN TXT "XhVGx_0VVeR5yiaGLHHXrRl2sAbZhI7IugMSdbfR4go" ``` #### 5. Additional HTTP headers. Your HTTP method call may require additional headers for Authorization, ContentType, Accept, Cookies, etc. for the DNS providers API to add/remove the txt record. You can export _H*n* (_H1, _H2, _H3, etc.) environment variables with the [HTTP header](https://en.wikipedia.org/wiki/List_of_HTTP_header_fields) needed: ```sh ... myusername="$MYAPI_username" mypassword="$MYAPI_password" mycredentials="$(printf "%s" "$myusername:$mypassword" | _base64)" export _H1="Authorization: Basic $mycredentials" export _H2="Content-Type: application/json" ... ``` Just number the _H*n* in the order that you need the headers. Please review [these](https://github.com/acmesh-official/acme.sh/blob/master/dnsapi/dns_zone.sh#L110) [few](https://github.com/acmesh-official/acme.sh/blob/master/dnsapi/dns_desec.sh#L151) [examples](https://github.com/acmesh-official/acme.sh/blob/master/dnsapi/dns_jd.sh#L184) for inspiration. This is the only way to pass the equivalent wget's _--user_ and _--password_ and curl's _--user_ parameters. #### 6. Process the API Response. The API response could be in text, JSON or XML format. Here are a lot of functions to process strings: ```sh ... _startswith() _endswith() _contains() _egrep_o() ... ``` You can use `sed`, `grep`, `cut`, `paste` etc, Do not use `awk` at all. ### 7. Guide for the rm function. The steps are the same as the add function. Please take care that the rm function and add function are called in 2 different isolated subshells. So, you can not pass any env vars from the add function to the rm function. You must re-do all the preparations of the add function here too. See: https://github.com/acmesh-official/acme.sh/blob/8ded524236347d5a1f7a3169809cab9cf363a1c8/dnsapi/dns_cf.sh#L106 ### 8. Please also check this bug to support the V2 wildcard cert: https://github.com/acmesh-official/acme.sh/issues/1261 ### 9. Please create a new issue for future bugs Please report a new issue here: `" Report bugs to xxxx DNS API"` https://github.com/acmesh-official/acme.sh/issues And please watch to that issue. Any future bug will be reported there. Example: https://github.com/acmesh-official/acme.sh/issues/2057 ### 10. Update the docs to include your DNS API usage. Please append your API at the end: https://github.com/acmesh-official/acme.sh/wiki/dnsapi2 You must to add an anchor with your DNS API name like ``. This will allow to quickly lookup your API instruction by a link https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_yourapi Also don't forget to add the issue link from step 9 like `Report any bugs or issues here`. ### 11. Add structural info description Your script should start with a [structured info description](https://github.com/acmesh-official/acme.sh/wiki/DNS-API-Structural-Info-description) to automatically generate a list of APIs and their variables. ### 12. Please read and follow the instruction before creating a pull request Please follow the guide: https://github.com/acmesh-official/acme.sh/wiki/DNS-API-Test See more code of conduct: https://github.com/acmesh-official/acme.sh/wiki/Code-of-conductacme.sh-0.0~git20250417.7502af3/DNS-API-Structural-Info-description.md000066400000000000000000000121311500024665000243350ustar00rootroot00000000000000# DNS API Structural Info description For GUI we need to show a list of options and basic description. So instead of using comments describe a provider info in a special variable that later will be read and parsed. The variable must be called like `dns_example_info` where the `example` is your provider code as in a file name. The basic example: ```sh # shellcheck disable=SC2034 dns_example_info='Example.org Site: Example.org Docs: github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_example Options: Example_Token API Token Issues: github.com/acmesh-official/acme.sh/issues/9000 Author: Your Name ' ``` The format is both human-readable and easy to parse. The `# shellcheck disable=SC2034` is needed to ignore an error that the var is not used. The `dns_example_info` declares a variable with a multi line text. At the first line is the title of of the API. If this is just a DNS provider then try use it's domain name. Please write long domains in a CamelCase e.g. `CloudFlare.com`. This will help a user to distinguish providers in a list. The `Site: Example.org` is a URL (without `https://`) to the provider's site. Sometimes it should be a dedicated DNS page: ```sh dns_aws_info='Amazon AWS Route53 domain API Site: docs.aws.amazon.com/route53/ ``` The `Docs: github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_example` is a link to Wiki page with instructions. Some providers may have own wiki page e.g. `Lexicon`. The `https://` at beginning is stripped. The `Options:` is a section with list of parameters (environment variables) to configure the provider. Each option should be declared on a separate line. The line ` Example_Token API Token` starts with one space and declares a variable `Example_Token` with a title `API Token`. You may have multiple options and you can specify default value and show if the option is required: Options: VARIABLE1 Title for the option1. VARIABLE2 Title for the option2. Default "default value". VARIABLE3 Title for the option3. A long description to show on UI. Optional. By default all the variables are mandatory. The `Optional.` is a special mark that the variable is not required. The `Default "default value".` is a special mark and the value between the double quotes will be used as a default. Such variable are optional. Only the first sentence will be a title so the the `A long description to show on UI` will be an extended description to show separately and it can be long and contain links. The HTML is not allowed in a title or description. A DNS provider may have alternative options like CloudFlare may use API KEY or API Token. You can use a second section `OptionsAlt:` section. See [dns_cf.sh](https://github.com/acmesh-official/acme.sh/blob/master/dnsapi/dns_cf.sh). The `Issues: github.com/acmesh-official/acme.sh/issues/9000` is a link to an support issue or a forum topic where you can reach an author to report a bug. At beginning you may omit it and we'll add ourselves once a PR is merged and the issue is created. The `https://` at beginning is stripped. The `Author: Your Name ` is an optional field with a developer name and email (is not required). The author can be a GitHub username `@yourname`. You may use a link e.g. `Author: Alex Loban `. Multiple authors should be separated with a comma `,` e.g. `Author: Wolfgang Ebner, Sven Neubuaer`. ## Domain aliases If a provider has multiple domains e.g. `AlibabaCloud.com` has an additional `Aliyun.com` then you can declare them in a dedicated field `Domains:`: ```sh dns_1984hosting_info='1984.hosting Domains: 1984.is Site: 1984.hosting ' ``` So here the https://1984.hosting is the main page but the https://1984.is is also used. So if user looking for the `1984.is` it may be confused it it see only the `1984.hosting`. The `Domains:` may be also useful to search a provider in a drop-down list with autocomplete. ## Extended description If the API is not for a specific provider but for a software (e.g. PowerDNS) or a protocol (e.g. nsupdate) then the title will be not a domain but a text. Also you may add a description on the next line(s) staring with a space: ```sh dns_acmedns_info='acme-dns Server API The acme-dns is a limited DNS server with RESTful API to handle ACME DNS challenges. Site: github.com/joohoi/acme-dns ' ``` See the [initial commit](https://github.com/acmesh-official/acme.sh/commit/6b7b5caf54ea0b45508e158db3748d00f48672f2#diff-defdf80606e9123d8383965fa2bd6281a2567dc76c7d246a5244b41ec43429feR3) for mare samples. ## Parsing Here a script (dash and ash complaint) to generate a list of all infos: ```sh #!/bin/ash for f in ./dnsapi/dns_*.sh do filename=$(basename -- "$f") dns_api="${filename%.*}" echo "$dns_api" dns_api_info_var="${dns_api}_info" # shellcheck source=./dnsapi/dns_*.sh . "$f" info="" eval info=\$$dns_api_info_var echo "$info" done ``` Now execute it and stored result to info.txt file: sh ./dns_info.sh > info.txt The resulted file has size of 40Kb bytes and gzipped it's about 10Kb. See example of how to parse it in JavaScript: https://github.com/yurt-page/acmesh-parse-dnsapi-infoacme.sh-0.0~git20250417.7502af3/DNS-API-Test.md000066400000000000000000000065551500024665000177070ustar00rootroot00000000000000 There is a CI workflow `DNS.yml` to test your DNS API when you send PR to add a new DNS API. This test suite uses GitHub actions. The purpose is to try your changes on one particular API across a bunch of different operating systems so that we have confidence your changes will work wherever this script is used. This test must be passing before your PR can get merged. However, as a limitation of github actions, the workflow `DNS.yml` can only run in your Forked repo when you push code. ## So, please enable Github Actions on your Forked repo first, and then push code to your repo, it will run there. If you have not enabled Github Actions before you push to your fork, unfortunately you'll need to trigger some kind of push in order for GitHub actions to realise it needs to run the workflow, so either push a new commit after enabling GitHub actions, roll your fork back to be even with the main repo, then push again, or delete your fork and re-push your changes. Once you've got GitHub Actions running the DNS API tests on your fork, we need to configure them so they can put your change through its paces. ### 1. An example DNS API We'll use this API as an example. It's called `dns_myapi`, and it takes two environment variable arguments, `MyDnsKey1`, and `MyDnsKey2`. To run it on the command line, we'd do this: ``` export MyDnsKey1=myValue1 export MyDnsKey2=myValue2 acme.sh --issue -d mytest.myExample.com --dns dns_myapi ``` ### 2. In order to test this particular API, we'd need to do this: 1. Go to your repository on GitHub. 1. Click on the “Settings” tab. 1. Scroll down to the “Security” section and click on “Secrets and variables”, then on “Actions” and finally on “New repository secret”. 1. Enter a name for your secret (e.g. TokenName1 ) and insert the corresponding value. 1. Click on “Add secret”. **The secrets are only visible to yourself, nobody else can read the secrets.** **You must create a separate secret for each variable. Each entry under “Add secret” only takes one name and one value** And we'd need to set the following secrets: ``` TokenName1 = MyDnsKey1 ``` ``` TokenValue1 = myValue1 ``` ``` TokenName2 = MyDnsKey2 ``` ``` TokenValue2 = myValue2 ``` ``` TEST_DNS = dns_myapi ``` ``` TestingDomain = mytest.myExample.com ``` ``` TEST_DNS_SLEEP = 120 ``` The `TEST_DNS_SLEEP` is the time (in seconds) to sleep to wait for your DNS records to propagate. Different DNS providers may require different propagate time, please ask your DNS provider support for the time. Usually, it's larger than `120` seconds. ## Note Note that in order to test a different API, you'd need different values, for example the Netlify API is run like this: ``` export NETLIFY_ACCESS_TOKEN="xxxx" acme.sh --issue -d mytest.myExample.com --dns dns_netlify ``` So we'd need to set the following secrets in GitHub: ``` TEST_DNS = dns_netlify ``` ``` TokenName1 = NETLIFY_ACCESS_TOKEN ``` ``` TokenValue1 = xxxx ``` ``` TestingDomain = mytest.myExample.com ``` Now the tests should be able to try out your change to the Netlify DNS API! # How to get a Solaris server If you need a solaris shell to debug your script, please see this project: https://github.com/vmactions/shell-solaris # How to get a FreeBSD server If you need a freebsd shell to debug your script, please see this project: https://github.com/vmactions/shell-freebsd acme.sh-0.0~git20250417.7502af3/DNS-alias-mode.md000066400000000000000000000124271500024665000203670ustar00rootroot00000000000000If your DNS provider doesn't support API access, or if you're concerned about security problems from giving the DNS API access to your main domain, then you can use DNS alias mode. For example, your main domain is **example.com**, which doesn't have API access, or you don't want to give the API access to acme.sh, since it's important. And you have another domain: **aliasDomainForValidationOnly.com**, which has a supported DNS API. This domain is less important, and maybe it's used for validation only. Ok, let's start. ### 1. First set domain CNAME: ```text _acme-challenge.example.com => _acme-challenge.aliasDomainForValidationOnly.com ``` or, in standard [DNS zone file](https://en.wikipedia.org/wiki/Zone_file) format, (like ISC BIND or NSD): ```text.zone_file _acme-challenge.example.com IN CNAME _acme-challenge.aliasDomainForValidationOnly.com. ``` - If you are using `Cloudflare`, do set `Proxy status` as `DNS only`. DON'T set it to ~Proxied~, it won't work! ### 2. Issue a cert: ```sh acme.sh --issue \ -d example.com --challenge-alias aliasDomainForValidationOnly.com --dns dns_cf ``` The Letsencrypt CA server checks the txt record of original domain `_acme-challenge.example.com` to validate your domain, but you have set the CNAME in step 1, so it goes forward to the aliased domain `_acme-challenge.aliasDomainForValidationOnly.com` to check. And acme.sh knows that, so it just added the correct txt record to `_acme-challenge.aliasDomainForValidationOnly.com`. So, it's done. you will get a cert for `example.com`, but you don't need to give the domain control out. ### 3. Share the same aliased domain: If you have multiple (sub)domains, you need add CNAME for each (sub)domain, but they can share the same aliased domain. For example, you can add the CNAME like: ```sh _acme-challenge.example.com => _acme-challenge.aliasDomainForValidationOnly.com _acme-challenge.www.example.com => _acme-challenge.aliasDomainForValidationOnly.com _acme-challenge.sub.example.com => _acme-challenge.aliasDomainForValidationOnly.com _acme-challenge.example.net => _acme-challenge.aliasDomainForValidationOnly.com _acme-challenge.example.org => _acme-challenge.aliasDomainForValidationOnly.com ``` And then issue cert like bellow: ```sh acme.sh --issue \ -d example.com --challenge-alias aliasDomainForValidationOnly.com --dns dns_cf \ -d www.example.com \ -d sub.example.com \ -d example.net \ -d example.org ``` Even with ACME v2 wildcard cert: ```sh acme.sh --issue \ -d example.com --challenge-alias aliasDomainForValidationOnly.com --dns dns_cf \ -d example.net \ -d example.org \ -d *.example.com \ -d *.example.net \ -d *.example.org ``` ### 4. Specify different aliased domains for each domain. Yes, you know, acme.sh supports to set the alias domains for each domain. Even with different dns provider: You can set CNAME like: ```sh _acme-challenge.example.com => _acme-challenge.aliasDomainForValidationOnly.com _acme-challenge.example.net => _acme-challenge.aliasDomainForValidationOnly2.com ``` Then issue cert: ```sh acme.sh --issue \ -d example.com --challenge-alias aliasDomainForValidationOnly.com --dns dns_cf \ -d example.net --challenge-alias aliasDomainForValidationOnly2.com ``` Even with different dns provider: ```sh acme.sh --issue \ -d example.com --challenge-alias aliasDomainForValidationOnly.com --dns dns_cf \ -d example.net --challenge-alias aliasDomainForValidationOnly2.com --dns dns_gd ``` Let's assume the first domain `aliasDomainForValidationOnly.com` is hosted at cloudflare, and the second is hosted at godaddy. ### 5. Mix dns alias and default dns auth You can get a certificate with domains where you can authenticate with dns and want to mix it with domains where you need to use dns alias mode. Use `--challenge-alias no` to mark the domain that doesn't use a dns alias. If we have direct acccess to set a txt record for *.example.com. The domain example.net must use dns alias. For extern1.example.net set a CNAME ```txt _acme-challenge.extern1.example.net => _acme-challenge.aliasDomainForValidationOnly.com ``` Then issue cert: ```sh ./acme.sh/acme.sh --issue \ -d host1.example.com --challenge-alias no \ -d host2.example.com --challenge-alias no \ -d extern1.example.net --challenge-alias aliasDomainForValidationOnly.com \ --dns dns_infoblox ``` ### 6. Last Do not remove the CNAME like : `_acme-challenge.example.com` after you issue the cert. It will be reused when acme.sh tries to renew the cert. The left cname record `_acme-challenge.example.com` doesn't harm your domain at all. Just keep it there. ### 7. challenge-alias or domain-alias We have another parameter: `--domain-alias`, it has the same meaning with `--challenge-alias`. But with `--domain-alias` you don't need to add `_acme-challenge.` prefix. For example, if you use `--challenge-alias`, you must set CNAME like bellow: ```sh CNAME: _acme-challenge.A.com => _acme-challenge.B.com ``` Then issue cert like: ```sh acme.sh --issue -d a.com --challenge-alias b.com --dns dns_cf ``` If you use `--domain-alias`, the CNAME should be like: ```sh CNAME: _acme-challenge.A.com => myalias.B.com ``` Then issue cert like: ```sh acme.sh --issue -d a.com --domain-alias myalias.B.com --dns dns_cf ``` acme.sh-0.0~git20250417.7502af3/DNS-manual-mode.md000066400000000000000000000035601500024665000205510ustar00rootroot00000000000000Warning: DNS manual mode can not renew automatically. If your domain provider offers an DNS API, it's highly recommended to use DNS API mode instead. With the DNS API mode, you can automate the renewals. If your domain provider does **not** offer an API where you can add/edit TXT records of your domain, it is recommended to use [DNS alias mode](https://github.com/Neilpang/acme.sh/wiki/DNS-alias-mode) instead. Or change the dns servers of your domain to anyone that support DNS api. DNS manual mode **should** be used for testing. If you do use it for your production server, remember to renew your certificate within 90 days. [Please, make sure you understand DNS manual mode](https://github.com/Neilpang/acme.sh/issues/1029). 1. First step: ```sh acme.sh --issue -d example.com --dns \ --yes-I-know-dns-manual-mode-enough-go-ahead-please ``` 2. Please add the TXT record to your DNS records. This step is required every time you renew your certificate. With DNS api mode, this step can be automated. 3. Now retry with `--renew` command. ```sh acme.sh --renew -d example.com \ --yes-I-know-dns-manual-mode-enough-go-ahead-please ``` *** **if your DNS _acme challenge fails when using renew, your respective CA will generate new _acme challenge,** _**make sure to wait 1 minute for DNS entries to reflect before using renew.**_ *** _**if you had issued a Staging/Production Certificate with SHA CSR then use the `--force` switch to overwrite any entries of old CER and issue fresh CER.**_ ```sh acme.sh --renew -d example.com \ --yes-I-know-dns-manual-mode-enough-go-ahead-please --force ``` _**if you had issued a Staging/Production Certificate with ECC CSR then use the `--ecc --force` switch to overwrite any entries of old CER and issue fresh CER.**_ ```sh acme.sh --renew -d example.com \ --yes-I-know-dns-manual-mode-enough-go-ahead-please --ecc --force ``` acme.sh-0.0~git20250417.7502af3/Deploy-ssl-certs-to-apache-server.md000066400000000000000000000025601500024665000242430ustar00rootroot00000000000000## 1. run acme.sh to copy the certificates to the correct location on the disk ### 1.1) create a sensible directory to store your apache certificates I chose /etc/apache2/2.2/ssl ``` mkdir -p /etc/apache2/2.2/ssl ``` ### 1.2) run acme.sh A few notes: * the parameters are stored in the .acme.sh configuration file, so get it right for your system as this file is read when the cron job runs * "reloadcmd" is dependent on your operating system, system V Linux systems use the command "service apache2 force-reload", Solaris based systems use "svcadm restart apache22" or similar ``` acme.sh --install-cert -d online.domain.com \ --cert-file /etc/apache2/2.2/ssl/online.domain.com-cert.pem \ --key-file /etc/apache2/2.2/ssl/online.domain.com-key.pem \ --fullchain-file /etc/apache2/2.2/ssl/letsencrypt.pem \ --reloadcmd "service apache2 force-reload" ``` ## 2. Set up your httpd.conf There are so many ways to do this, it would take a long list to write every variant, however the specific codes you will need to set in your httpd.conf (or ssl.conf, or httpd-ssl.conf) are: ``` SSLCertificateFile /etc/apache2/2.2/ssl/online.domain.com-cert.pem SSLCertificateKeyFile /etc/apache2/2.2/ssl/online.domain.com-key.pem SSLCertificateChainFile "/etc/apache2/2.2/ssl/letsencrypt.pem" SSLCACertificatePath "/etc/apache2/2.2/ssl/" SSLCACertificateFile "/etc/apache2/2.2/ssl/letsencrypt.pem" ``` acme.sh-0.0~git20250417.7502af3/Deploy-ssl-certs-to-nginx.md000066400000000000000000000002761500024665000226430ustar00rootroot00000000000000TODO see: 1. https://www.rmedgar.com/blog/using-acme-sh-with-nginx 1. http://www.cyberciti.biz/faq/how-to-configure-nginx-with-free-lets-encrypt-ssl-certificate-on-debian-or-ubuntu-linux/ acme.sh-0.0~git20250417.7502af3/Deploy-ssl-to-SolusVM.md000066400000000000000000000025461500024665000217540ustar00rootroot00000000000000### 1. SolusVM master with nginx stack: First of all, install acme.sh as described in the documentation. #### 1) Issue your certificate: acme.sh will try to validate your domain over http connection. That means the docroot is /usr/local/solusvm/www/.verification. Please check if you have this folder, else you can use /usr/local/solusvm/www as your docroot. ``` acme.sh --issue -d solusvm.yourdomain.com \ -w /usr/local/solusvm/www/.verification ``` Chenge 'solusvm.yourdomain.com' with your SolusVM master domain name. Remember you can add multiple domains (SANs) to your certificate using the -d option. Please check acme.sh wiki on how to do it. #### 1) Install the issued certificate to your SolusVM master: ``` acme.sh --installcert -d solusvm.yourdomain.com \ --keypath /usr/local/svmstack/nginx/ssl/ssl.key \ --fullchainpath /usr/local/svmstack/nginx/ssl/ssl.crt \ --reloadcmd "service svmstack-nginx restart; \ /usr/local/svmstack/sshwebsocket/quit; \ /usr/local/svmstack/sshwebsocket/port_check; \ cd /usr/local/svmstack/nginx/ssl && cat ssl.key ssl.crt > ssl.pem" ``` This command will install the fullchain and the private key to /usr/local/svmstack/nginx/ssl/. After that, it will restart the web server, restart sshwebsocket (used for HTML5 console) and then generate the ssl.pem file needed for novnc websockify. ### 2. SolusVM master with lighttpd stack: TODOacme.sh-0.0~git20250417.7502af3/Donate-list.md000066400000000000000000000072731500024665000201200ustar00rootroot00000000000000## Thanks to those who donate: (If you want to be listed with your website link here, please write email to me: donate@neilpang.com ) (You can also find me on Twitter: [@neilpangxa](https://twitter.com/neilpangxa)) (In date time order, from the early to the latest) 1. Third Eye 1. Chan Davy 1. Stephan Herbers 1. Armando Lüscher 1. Barry van Someren 1. Robert Wetzlmayr 1. Ricardo Cabrera 1. Coffeesprout ICT services 1. myGeiger Scientific Instruments Oy 1. shimile@GitHub 1. John Elliot ProgClub 1. Dan Langille 1. Haiku Lab Limited 1. Miroslav Lachman 1. Yannick Grangé 1. Christian Kraus 1. Jean-Baptiste Marie 1. Steven Grantz 1. Chris Gelatt 1. Petr Líbal 1. Neil Sabol 1. Ovchinnikov Alexey 1. allegronet.de (Klaus Lehmann) 1. Maurice Bleuel 1. Romain Muller 1. Stefan Daschek 1. Andreas Vögele 1. Moritz Süß 1. Simon Hengchen 1. Chen Wei Chi 1. Allen Thompson 1. Peter Berbec 1. Гончаров Владимир 1. Stuart Friedberg 1. Scott Aitken 1. Bob Geddes 1. David Yang 1. [Techno FAQ](https://technofaq.org) 1. Alex King 1. Seth Schoen 1. Andre D Henry 1. Simon Gaynor 1. Benedykt Mis 1. Andris Reinman 1. Walther Schubert 1. Mathew Rupp 1. Richard Shea 1. Vladislav Bakayev 1. Georgi Petrov 1. Hank Oxford 1. Ondrej Sury 1. Feng Gao 1. David Tourel [Maildrop](https://www.maildrop.fr) 1. Falinder Patric 1. Ovchinnikov Alexey 1. Demiri Adil 1. Forsythe R G 1. Tekampe Nils 1. Zimmermann Christoph 1. Bucciarelli Mark 1. Muller Romain 1. H. Meier Thomas 1. Xibo Signage Ltd 1. Rzepka Norman 1. Biere Christian 1. Burkard Marius 1. Autie Nicolas 1. Campitelli da Silva Pinto Vinícius 1. Haslinger Daniel 1. Drolet Jean-Yves 1. Zensiri Alexander 1. Losev Vladimir 1. Wyde Patrik 1. G2Soft.Net 1. Hueskes Robin 1. Tichý Petr 1. Herbers Stephan 1. Васильев​Константин 1. Pérez Fuster José Joaquín 1. Strasser Joel 1. Growls LLC 1. Miehler Axel 1. Dalla Stella Marco 1. Zhou Hao 1. Silberman Jonathan 1. Jäger Max 1. Gollnick Joerg 1. Petkov Petko 1. Kevin Rosbach 1. Hueskes Robin 1. ByrdBrain.com 1. Jensen Thomas 1. [The Citizen](http://thecitizen.pk) ## 微信捐助列表: 发现有人微信捐助了. 但是微信这个真是看不见名字, 只能全部匿名了. 欢迎大家自己补上: (排名不分先后) 1. 匿名 2. 匿名 3. 匿名 4. 匿名 1. 匿名 2. 匿名 3. 匿名 4. 匿名 1. 匿名 2. 匿名 3. 匿名 4. 匿名 4. 匿名 4. 匿名 4. 匿名 4. 匿名 4. 匿名 4. 匿名 4. 匿名 5. *尔 6. c*l 7. *水 8. d*g 9. *哥 10. *荣 11. 张一菜 1. _*_ 1. *j 1. *良 1. M*t 1. *😊 1. *兔 1. *想 1. 爱*Q 1. M*k 1. *司 1. j*e 1. *亮 1. *嘛 1. D*t 1. *月 1. C*n 1. R*i 1. *力 1. *鸟 1. N*i 1. *飞 1. *1 1. *翟 1. J*s 1. *店 1. *子 1. *木 1. *人 1. *孩 1. Arthur 1. *兵 1. *昊 1. *健 1. *e 1. T*n 1. n*o 1. *l 1. *川 1. M*n 1. *神 1. *霓 ## 支付宝 现在也补上列表, 可能有遗漏, 欢迎大家自己补上: (排名不分先后) 1. *宇 2. *宇腾 3. *文龙 4. *明军 5. *士军 6. *超 7. *博涵 8. *祖辉 9. *欣磊 10. *智超 11. *瑞祥 12. *志伟 13. *世超 14. *志杰 15. *伟 16. *明 17. *博 18. *凯升 19. *进 20. *泉波 21. *松 22. *森 23. *昂 24. *晓迪 25. *浩睿 26. *晓枫 27. *麟 28. *锐錩 29. *坚 30. *嘉康 31. *旭光 1. *泽宇 1. *敏 1. *腾飞 1. *开 1. *浦城 1. *云轩 1. *山林 1. *友德 1. *涛 1. *桃 1. *雁辉 1. *淑豪 1. *峻源 1. *亚庆 1. *秋雨 1. *晨 1. *少龙 1. *磊 1. *晶晶 1. *佳炜 1. *宇蓝 1. *毅博 1. *勇 1. *组涛 1. *翔 # Sponsors: [![quantumca-acmesh-logo](https://user-images.githubusercontent.com/8305679/183255712-634ee1db-bb61-4c03-bca0-bacce99e078c.svg)](https://www.quantumca.com.cn/?__utm_source=acmesh-donation) acme.sh-0.0~git20250417.7502af3/Enable-acme.sh-log.md000066400000000000000000000014611500024665000212070ustar00rootroot00000000000000## 1. You can use `--log` parameter in any command to enable log file. Once enabled, the log will take effect for any operations in future. Example: install and enable log. ``` acme.sh --install --log ``` If you forget to enable log when installing, you can enable log by any command. Example: enable log when issuing a cert: ``` acme.sh --issue .... --log ``` ## 2. Set the log file path. The default log file is in `~/.acme.sh/acme.sh.log` And you can specify a log file path ``` acme.sh --issue ..... --log "/path/to/mylog.log" ``` ## 3. You can also specify log level. The default log level is `1`, it will output the log info same as `--debug` This is enough for most cases. You can also specify log level. set log level to `2` ``` acme.sh --issue ..... --log --log-level 2 ``` acme.sh-0.0~git20250417.7502af3/Exit-Codes.md000066400000000000000000000006711500024665000176740ustar00rootroot00000000000000# Request exit codes There currently are three exit codes: **0**: certificate request successful **1**: certificate request failed **2**: certificate still valid, request skipped ## Cronjobs If you run `acme.sh --cron` and all certificates are still valid (so nothing is renewd), the exit code will be is 0. Only if you run `acme.sh --renew --domain example.com` and it is still valid, the exit code will be 2 as stated above.acme.sh-0.0~git20250417.7502af3/Explicitly-use-DOH.md000066400000000000000000000003611500024665000212540ustar00rootroot00000000000000Reference to https://github.com/acmesh-official/acme.sh/issues/3487 ```bash DOH_CLOUDFLARE=1 DOH_GOOGLE=2 DOH_ALI=3 DOH_DP=4 ``` Explicitly use Aliyun DNS: ```bash cd .acme.sh echo "export DOH_USE=3" >> acme.sh.env source acme.sh.env ```acme.sh-0.0~git20250417.7502af3/Google-Public-CA.md000066400000000000000000000000401500024665000206270ustar00rootroot00000000000000See [[Google Trust Services CA]]acme.sh-0.0~git20250417.7502af3/Google-Trust-Services-CA.md000066400000000000000000000306071500024665000223270ustar00rootroot00000000000000Google just announced its free ACME server: https://cloud.google.com/blog/products/identity-security/automate-public-certificate-lifecycle-management-via--acme-client-api It supports multiple domains and wildcard domains. The lifetime of the cert is 90 days, too. 1. Follow this guide to create your EAB key and EAB id: https://cloud.google.com/public-certificate-authority/docs/quickstart 2. OK, Done. You can register an ACME and issue certs now: ``` acme.sh --register-account -m myemail@example.com --server google \ --eab-kid xxxxxxx \ --eab-hmac-key xxxxxxx acme.sh --issue --server google \ -d example.com --dns dns_googledomains ``` Here is an example cert: ``` -----BEGIN CERTIFICATE----- MIIFejCCBGKgAwIBAgIRAIQeIGxefiDpDgAAAAADL4YwDQYJKoZIhvcNAQELBQAw RjELMAkGA1UEBhMCVVMxIjAgBgNVBAoTGUdvb2dsZSBUcnVzdCBTZXJ2aWNlcyBM TEMxEzARBgNVBAMTCkdUUyBDQSAxUDUwHhcNMjIwMzMwMTMzNDM1WhcNMjIwNjI4 MTMzNDM0WjAbMRkwFwYDVQQDExBnY2EubmVpbHBhbmcuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvogb9TZAG+wfJ9VA/hcf3NfW/BM8bx+hXfdq BtLAlMhxNRzhI+TBj1y2mFuYPuq7C+cmJVmmcG+zuMka33nEX7RFCn2AMcp2Dh7m frw2jfqhruBqYiaCt74FLHz//O+WNY68LPdYgEuKdh1W0UE5tgcn7sIUGv3ClQVG u5kit7EYViAXD9ey+kImLgdqFeD1n2v79F+nYmu/nAJ8lPXHk1ADmjATxP7tNWmQ XopH/1ThWeiMzb+nCb+y6fs7Fw89Q8ECP3Q+HbBzyWh3x8zptZbb1bh6SrJ7Uz3c yz/M5hcn+EbX5ZNWsoNnYu5O8GPwC5MbLnKEgVQyjUJ0Q34bJQIDAQABo4ICjDCC AogwDgYDVR0PAQH/BAQDAgWgMBMGA1UdJQQMMAoGCCsGAQUFBwMBMAwGA1UdEwEB /wQCMAAwHQYDVR0OBBYEFErTzUpCbi/cp3bNK7i1cc+AF+J0MB8GA1UdIwQYMBaA FNX8ng3fHsrdCJeXbivFX8Ur9ey4MHgGCCsGAQUFBwEBBGwwajA1BggrBgEFBQcw AYYpaHR0cDovL29jc3AucGtpLmdvb2cvcy9ndHMxcDUvRXZZZFdCRVNaY1kwMQYI KwYBBQUHMAKGJWh0dHA6Ly9wa2kuZ29vZy9yZXBvL2NlcnRzL2d0czFwNS5kZXIw LwYDVR0RBCgwJoIQZ2NhLm5laWxwYW5nLmNvbYISKi5nY2EubmVpbHBhbmcuY29t MCEGA1UdIAQaMBgwCAYGZ4EMAQIBMAwGCisGAQQB1nkCBQMwPAYDVR0fBDUwMzAx oC+gLYYraHR0cDovL2NybHMucGtpLmdvb2cvZ3RzMXA1L2h0QUlJRUV0WGNZLmNy bDCCAQUGCisGAQQB1nkCBAIEgfYEgfMA8QB2AEHIyrHfIkZKEMahOglCh15OMYsb A+vrS8do8JBilgb2AAABf9s/9SMAAAQDAEcwRQIhAJXQxese0g6ilHanInWFe9wP yZp5jTbIKRZ8T/0DJrmAAiBQcQ4U5bOcvuwHq63IdDTQ3JVLXibT+RMujzCZl1lW jQB3ACl5vvCeOTkh8FZzn2Old+W+V32cYAr4+U1dJlwlXceEAAABf9s/9HoAAAQD AEgwRgIhAPN4hN8H84vkDbz6FQk8/VfypAfnj0J+F9kCwsndMtSBAiEAprEIgKtM i0totuQ8YQK69oATZ9ancTPAE4w9iGBwGDswDQYJKoZIhvcNAQELBQADggEBAIE4 tkICIps1tXncYwnERecZDPeyk7BaeiS4D2gcFnP5zRJI9s6hpwlDLumcAcNMF4DV xT1Xm/GDkvv3c+tAgcYyoKRjeLZcgzZb1TVnG/yWT3Q+vcyNvYy/UuZQuF019plC oCvo5zyV0qeArps3WtyJOQ5QGuEmp8Vr3nQcG0MJpXNgMV1wE9S0TWn7AJ+x2csr G8iQjR+0nJBVqnVCuRDArh2qYFQd/W5zFj46n/Edzx0jrc38RiBorx4IT0Pfm23o +XvkdKDqdDquzq7FdYa5wDXlwQJOuf4BRPBo7a5f4fJpRcL3QSDwewSSHhDKQXFH 74yQYKaw0gRoE71IEmk= -----END CERTIFICATE----- ``` The full chain: ``` -----BEGIN CERTIFICATE----- MIIFejCCBGKgAwIBAgIRAIQeIGxefiDpDgAAAAADL4YwDQYJKoZIhvcNAQELBQAw RjELMAkGA1UEBhMCVVMxIjAgBgNVBAoTGUdvb2dsZSBUcnVzdCBTZXJ2aWNlcyBM TEMxEzARBgNVBAMTCkdUUyBDQSAxUDUwHhcNMjIwMzMwMTMzNDM1WhcNMjIwNjI4 MTMzNDM0WjAbMRkwFwYDVQQDExBnY2EubmVpbHBhbmcuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvogb9TZAG+wfJ9VA/hcf3NfW/BM8bx+hXfdq BtLAlMhxNRzhI+TBj1y2mFuYPuq7C+cmJVmmcG+zuMka33nEX7RFCn2AMcp2Dh7m frw2jfqhruBqYiaCt74FLHz//O+WNY68LPdYgEuKdh1W0UE5tgcn7sIUGv3ClQVG u5kit7EYViAXD9ey+kImLgdqFeD1n2v79F+nYmu/nAJ8lPXHk1ADmjATxP7tNWmQ XopH/1ThWeiMzb+nCb+y6fs7Fw89Q8ECP3Q+HbBzyWh3x8zptZbb1bh6SrJ7Uz3c yz/M5hcn+EbX5ZNWsoNnYu5O8GPwC5MbLnKEgVQyjUJ0Q34bJQIDAQABo4ICjDCC AogwDgYDVR0PAQH/BAQDAgWgMBMGA1UdJQQMMAoGCCsGAQUFBwMBMAwGA1UdEwEB /wQCMAAwHQYDVR0OBBYEFErTzUpCbi/cp3bNK7i1cc+AF+J0MB8GA1UdIwQYMBaA FNX8ng3fHsrdCJeXbivFX8Ur9ey4MHgGCCsGAQUFBwEBBGwwajA1BggrBgEFBQcw AYYpaHR0cDovL29jc3AucGtpLmdvb2cvcy9ndHMxcDUvRXZZZFdCRVNaY1kwMQYI KwYBBQUHMAKGJWh0dHA6Ly9wa2kuZ29vZy9yZXBvL2NlcnRzL2d0czFwNS5kZXIw LwYDVR0RBCgwJoIQZ2NhLm5laWxwYW5nLmNvbYISKi5nY2EubmVpbHBhbmcuY29t MCEGA1UdIAQaMBgwCAYGZ4EMAQIBMAwGCisGAQQB1nkCBQMwPAYDVR0fBDUwMzAx oC+gLYYraHR0cDovL2NybHMucGtpLmdvb2cvZ3RzMXA1L2h0QUlJRUV0WGNZLmNy bDCCAQUGCisGAQQB1nkCBAIEgfYEgfMA8QB2AEHIyrHfIkZKEMahOglCh15OMYsb A+vrS8do8JBilgb2AAABf9s/9SMAAAQDAEcwRQIhAJXQxese0g6ilHanInWFe9wP yZp5jTbIKRZ8T/0DJrmAAiBQcQ4U5bOcvuwHq63IdDTQ3JVLXibT+RMujzCZl1lW jQB3ACl5vvCeOTkh8FZzn2Old+W+V32cYAr4+U1dJlwlXceEAAABf9s/9HoAAAQD AEgwRgIhAPN4hN8H84vkDbz6FQk8/VfypAfnj0J+F9kCwsndMtSBAiEAprEIgKtM i0totuQ8YQK69oATZ9ancTPAE4w9iGBwGDswDQYJKoZIhvcNAQELBQADggEBAIE4 tkICIps1tXncYwnERecZDPeyk7BaeiS4D2gcFnP5zRJI9s6hpwlDLumcAcNMF4DV xT1Xm/GDkvv3c+tAgcYyoKRjeLZcgzZb1TVnG/yWT3Q+vcyNvYy/UuZQuF019plC oCvo5zyV0qeArps3WtyJOQ5QGuEmp8Vr3nQcG0MJpXNgMV1wE9S0TWn7AJ+x2csr G8iQjR+0nJBVqnVCuRDArh2qYFQd/W5zFj46n/Edzx0jrc38RiBorx4IT0Pfm23o +XvkdKDqdDquzq7FdYa5wDXlwQJOuf4BRPBo7a5f4fJpRcL3QSDwewSSHhDKQXFH 74yQYKaw0gRoE71IEmk= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIFjDCCA3SgAwIBAgINAgO8UKMnU/CRgCLt8TANBgkqhkiG9w0BAQsFADBHMQsw CQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZpY2VzIExMQzEU MBIGA1UEAxMLR1RTIFJvb3QgUjEwHhcNMjAwODEzMDAwMDQyWhcNMjcwOTMwMDAw MDQyWjBGMQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZp Y2VzIExMQzETMBEGA1UEAxMKR1RTIENBIDFQNTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBALOC8CSMvy2Hr7LZp676yrpE1ls+/rL3smUW3N4Q6E8tEFha KIaHoe5qs6DZdU9/oVIBi1WoSlsGSMg2EiWrifnyI1+dYGX5XNq+OuhcbX2c0IQY hTDNTpvsPNiz4ZbU88ULZduPsHTL9h7zePGslcXdc8MxiIGvdKpv/QzjBZXwxRBP ZWP6oK/GGD3Fod+XedcFibMwsHSuPZIQa4wVd90LBFf7gQPd6iI01eVWsvDEjUGx wwLbYuyA0P921IbkBBq2tgwrYnF92a/Z8V76wB7KoBlcVfCA0SoMB4aQnzXjKCtb 7yPIox2kozru/oPcgkwlsE3FUa2em9NbhMIaWukCAwEAAaOCAXYwggFyMA4GA1Ud DwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwEgYDVR0T AQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU1fyeDd8eyt0Il5duK8VfxSv17LgwHwYD VR0jBBgwFoAU5K8rJnEaK0gnhS9SZizv8IkTcT4waAYIKwYBBQUHAQEEXDBaMCYG CCsGAQUFBzABhhpodHRwOi8vb2NzcC5wa2kuZ29vZy9ndHNyMTAwBggrBgEFBQcw AoYkaHR0cDovL3BraS5nb29nL3JlcG8vY2VydHMvZ3RzcjEuZGVyMDQGA1UdHwQt MCswKaAnoCWGI2h0dHA6Ly9jcmwucGtpLmdvb2cvZ3RzcjEvZ3RzcjEuY3JsME0G A1UdIARGMEQwOAYKKwYBBAHWeQIFAzAqMCgGCCsGAQUFBwIBFhxodHRwczovL3Br aS5nb29nL3JlcG9zaXRvcnkvMAgGBmeBDAECATANBgkqhkiG9w0BAQsFAAOCAgEA bGMn7iPf5VJoTYFmkYXffWXlWzcxCCayB12avrHKAbmtv5139lEd15jFC0mhe6HX 02jlRA+LujbdQoJ30o3d9T/768gHmJPuWtC1Pd5LHC2MTex+jHv+TkD98LSzWQIQ UVzjwCv9twZIUX4JXj8P3Kf+l+d5xQ5EiXjFaVkpoJo6SDYpppSTVS24R7XplrWf B82mqz4yisCGg8XBQcifLzWODcAHeuGsyWW1y4qn3XHYYWU5hKwyPvd6NvFWn1ep QW1akKfbOup1gAxjC2l0bwdMFfM3KKUZpG719iDNY7J+xCsJdYna0Twuck82GqGe RNDNm6YjCD+XoaeeWqX3CZStXXZdKFbRGmZRUQd73j2wyO8weiQtvrizhvZL9/C1 T//Oxvn2PyonCA8JPiNax+NCLXo25D2YlmA5mOrR22Mq63gJsU4hs463zj6S8ZVc pDnQwCvIUxX10i+CzQZ0Z5mQdzcKly3FHB700FvpFePqAgnIE9cTcGW/+4ibWiW+ dwnhp2pOEXW5Hk3xABtqZnmOw27YbaIiom0F+yzy8VDloNHYnzV9/HCrWSoC8b6w 0/H4zRK5aiWQW+OFIOb12stAHBk0IANhd7p/SA9JCynr52Fkx2PRR+sc4e6URu85 c8zuTyuN3PtYp7NlIJmVuftVb9eWbpQ99HqSjmMd320= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIFYjCCBEqgAwIBAgIQd70NbNs2+RrqIQ/E8FjTDTANBgkqhkiG9w0BAQsFADBX MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UE CxMHUm9vdCBDQTEbMBkGA1UEAxMSR2xvYmFsU2lnbiBSb290IENBMB4XDTIwMDYx OTAwMDA0MloXDTI4MDEyODAwMDA0MlowRzELMAkGA1UEBhMCVVMxIjAgBgNVBAoT GUdvb2dsZSBUcnVzdCBTZXJ2aWNlcyBMTEMxFDASBgNVBAMTC0dUUyBSb290IFIx MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAthECix7joXebO9y/lD63 ladAPKH9gvl9MgaCcfb2jH/76Nu8ai6Xl6OMS/kr9rH5zoQdsfnFl97vufKj6bwS iV6nqlKr+CMny6SxnGPb15l+8Ape62im9MZaRw1NEDPjTrETo8gYbEvs/AmQ351k KSUjB6G00j0uYODP0gmHu81I8E3CwnqIiru6z1kZ1q+PsAewnjHxgsHA3y6mbWwZ DrXYfiYaRQM9sHmklCitD38m5agI/pboPGiUU+6DOogrFZYJsuB6jC511pzrp1Zk j5ZPaK49l8KEj8C8QMALXL32h7M1bKwYUH+E4EzNktMg6TO8UpmvMrUpsyUqtEj5 cuHKZPfmghCN6J3Cioj6OGaK/GP5Afl4/Xtcd/p2h/rs37EOeZVXtL0m79YB0esW CruOC7XFxYpVq9Os6pFLKcwZpDIlTirxZUTQAs6qzkm06p98g7BAe+dDq6dso499 iYH6TKX/1Y7DzkvgtdizjkXPdsDtQCv9Uw+wp9U7DbGKogPeMa3Md+pvez7W35Ei Eua++tgy/BBjFFFy3l3WFpO9KWgz7zpm7AeKJt8T11dleCfeXkkUAKIAf5qoIbap sZWwpbkNFhHax2xIPEDgfg1azVY80ZcFuctL7TlLnMQ/0lUTbiSw1nH69MG6zO0b 9f6BQdgAmD06yK56mDcYBZUCAwEAAaOCATgwggE0MA4GA1UdDwEB/wQEAwIBhjAP BgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTkrysmcRorSCeFL1JmLO/wiRNxPjAf BgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzBgBggrBgEFBQcBAQRUMFIw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnBraS5nb29nL2dzcjEwKQYIKwYBBQUH MAKGHWh0dHA6Ly9wa2kuZ29vZy9nc3IxL2dzcjEuY3J0MDIGA1UdHwQrMCkwJ6Al oCOGIWh0dHA6Ly9jcmwucGtpLmdvb2cvZ3NyMS9nc3IxLmNybDA7BgNVHSAENDAy MAgGBmeBDAECATAIBgZngQwBAgIwDQYLKwYBBAHWeQIFAwIwDQYLKwYBBAHWeQIF AwMwDQYJKoZIhvcNAQELBQADggEBADSkHrEoo9C0dhemMXoh6dFSPsjbdBZBiLg9 NR3t5P+T4Vxfq7vqfM/b5A3Ri1fyJm9bvhdGaJQ3b2t6yMAYN/olUazsaL+yyEn9 WprKASOshIArAoyZl+tJaox118fessmXn1hIVw41oeQa1v1vg4Fv74zPl6/AhSrw 9U5pCZEt4Wi4wStz6dTZ/CLANx8LZh1J7QJVj2fhMtfTJr9w4z30Z209fOU0iOMy +qduBmpvvYuR7hZL6Dupszfnw0Skfths18dG9ZKb59UhvmaSGZRVbNQpsg3BZlvi d0lIKO2d1xozclOzgjXPYovJJIultzkMu34qQb9Sz/yilrbCgj8= -----END CERTIFICATE----- ``` Human readable format: ``` Certificate: Data: Version: 3 (0x2) Serial Number: 84:1e:20:6c:5e:7e:20:e9:0e:00:00:00:00:03:2f:86 Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=Google Trust Services LLC, CN=GTS CA 1P5 Validity Not Before: Mar 30 13:34:35 2022 GMT Not After : Jun 28 13:34:34 2022 GMT Subject: CN=gca.neilpang.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:be:88:1b:f5:36:40:1b:ec:1f:27:d5:40:fe:17: 1f:dc:d7:d6:fc:13:3c:6f:1f:a1:5d:f7:6a:06:d2: c0:94:c8:71:35:1c:e1:23:e4:c1:8f:5c:b6:98:5b: 98:3e:ea:bb:0b:e7:26:25:59:a6:70:6f:b3:b8:c9: 1a:df:79:c4:5f:b4:45:0a:7d:80:31:ca:76:0e:1e: e6:7e:bc:36:8d:fa:a1:ae:e0:6a:62:26:82:b7:be: 05:2c:7c:ff:fc:ef:96:35:8e:bc:2c:f7:58:80:4b: 8a:76:1d:56:d1:41:39:b6:07:27:ee:c2:14:1a:fd: c2:95:05:46:bb:99:22:b7:b1:18:56:20:17:0f:d7: b2:fa:42:26:2e:07:6a:15:e0:f5:9f:6b:fb:f4:5f: a7:62:6b:bf:9c:02:7c:94:f5:c7:93:50:03:9a:30: 13:c4:fe:ed:35:69:90:5e:8a:47:ff:54:e1:59:e8: 8c:cd:bf:a7:09:bf:b2:e9:fb:3b:17:0f:3d:43:c1: 02:3f:74:3e:1d:b0:73:c9:68:77:c7:cc:e9:b5:96: db:d5:b8:7a:4a:b2:7b:53:3d:dc:cb:3f:cc:e6:17: 27:f8:46:d7:e5:93:56:b2:83:67:62:ee:4e:f0:63: f0:0b:93:1b:2e:72:84:81:54:32:8d:42:74:43:7e: 1b:25 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Key Identifier: 4A:D3:CD:4A:42:6E:2F:DC:A7:76:CD:2B:B8:B5:71:CF:80:17:E2:74 X509v3 Authority Key Identifier: keyid:D5:FC:9E:0D:DF:1E:CA:DD:08:97:97:6E:2B:C5:5F:C5:2B:F5:EC:B8 Authority Information Access: OCSP - URI:http://ocsp.pki.goog/s/gts1p5/EvYdWBESZcY CA Issuers - URI:http://pki.goog/repo/certs/gts1p5.der X509v3 Subject Alternative Name: DNS:gca.neilpang.com, DNS:*.gca.neilpang.com X509v3 Certificate Policies: Policy: 2.23.140.1.2.1 Policy: 1.3.6.1.4.1.11129.2.5.3 X509v3 CRL Distribution Points: Full Name: URI:http://crls.pki.goog/gts1p5/htAIIEEtXcY.crl 1.3.6.1.4.1.11129.2.4.2: ......v.A...."FJ...:.B.^N1.....K.h..b........?.#.....G0E.!..........v."u.{....y.6.).|O..&... Pq...........t4...K^&.....0..YV..w.)y...99!.Vs.c.w..W}.` ....<.W.....B~......2...!......L.Kh.. ``` After issuing, the cert will be automatically renewed every 60 days. 3) Install the cert to Proxmox: ``` /root/.acme.sh/acme.sh --installcert -d \ --certpath /etc/pve/local/pveproxy-ssl.pem \ --keypath /etc/pve/local/pveproxy-ssl.key \ --capath /etc/pve/local/pveproxy-ssl.pem \ --reloadcmd "systemctl restart pveproxy" ``` Ok, it's done. Open the link: `https://:8006` ## 3. How to get pkcs12(pfx) format: After you issue the cert, you can use the `toPkcs` command to convert the cert to pkcs12(pfx) format ``` acme.sh --toPkcs -d [--password pfx-password] ``` ## 4. How to run on Windows with Cygwin or git bash. 1) Download cygwin installer: setup-x86.exe or setup-x86_64.exe from: [https://cygwin.com/](https://cygwin.com/) 2) In the installer, select: Net: `curl` and Net: `socat` to install. 3) After install finished, you can open the Cygwin window and use `curl` to install `acme.sh`online: [https://github.com/acmesh-official/acme.sh/wiki#1-how-to-install](https://github.com/acmesh-official/acme.sh/wiki#1-how-to-install) 4) A scheduler task will be installed in your Windows scheduler to renew your certs. ## 5. License Copyright: acme.sh wiki contributors License: GNU General Public License version 3 or any later version acme.sh-0.0~git20250417.7502af3/How-to-debug-acme.sh.md000066400000000000000000000031151500024665000215010ustar00rootroot00000000000000Use `--debug` parameter to output detailed debug info. For example: ``` acme.sh --issue ......... --debug ``` To output more detailed info: ``` acme.sh --issue .......... --debug 2 ``` ### Common Root Cause of issue: #### Port 80 is blocked If your ISP blocks port 80, any webroot based authentication will fail You can test this by running this command from OUTSIDE your local network. `curl -IkL -m20 http://[binanceearn.org]` ### Common Errors using DNS API: #### Mistake 1: Clumsy fingers - newline in `~/.acme.sh/account.conf` If you type in the api key or private key and accidentally put in a newline or a typo, check and ensure the keys look right in `~/.acme.sh/account.conf` #### I still see my old keys (when moving from letsencrypt bot to .acme.sh) Needed step - point nginx configuration to new acme based keys If you still see the old keys being used, even after finally getting the dns based authentication to work. You may need to comment out the previous keys from the letsencrypt bot, and point to the new folder: > `# RSA certificate` > > #ssl_certificate /etc/letsencrypt/live/[binanceearn.org]/fullchain.pem; # managed by Certbot > > #ssl_certificate_key /etc/letsencrypt/live/[binanceearn.org]/privkey.pem; # managed by Certbot > > ssl_certificate [your home directory]/.acme.sh/[binanceearn.org]/fullchain.cer; > > ssl_certificate_key [your home directory]/.acme.sh//[your domain].key; #### Do I need to include the webroot `-w [your webroot]` for DNS? No! You'll end up back failing the port 80 access to your webroot folder if that was your issue.acme.sh-0.0~git20250417.7502af3/How-to-debug-acme.sh:-No-such-file-or-directory.md000066400000000000000000000003151500024665000264410ustar00rootroot00000000000000www.moonsky.ir: Invalid status. Verification error details: 2606:4700:3031::6815:f34: Invalid response from http://www.moonsky.ir/.well-known/acme-challenge/m8hspk-oSR-iYCXLZoqnq71AqFlNvY8UzUxgmK6JRxs: 403acme.sh-0.0~git20250417.7502af3/How-to-install.md000066400000000000000000000050701500024665000205470ustar00rootroot00000000000000Update the Linux/BSD system with latest CA bundle and patches from System Update otherwise some issues may occur when generating your free SSL certificates. Once completed begin with the install procedure below. - CentOs: `yum update ca-certificates` - Debian: `apt update ; apt install ca-certificates` (updates package if already installed) \ also applies to Debian-based distros like Ubuntu, LinuxMint, etc. ## 1. Install from web: https://get.acme.sh Install https://github.com/acmesh-official/acme.sh ``` curl https://get.acme.sh | sh -s email=my@example.com ``` or ``` wget -O - https://get.acme.sh | sh -s email=my@example.com ``` ## 2. Or, install from GitHub: ``` curl https://raw.githubusercontent.com/acmesh-official/acme.sh/master/acme.sh | sh -s -- --install-online -m my@example.com ``` or: ``` wget -O - https://raw.githubusercontent.com/acmesh-official/acme.sh/master/acme.sh | sh -s -- --install-online -m my@example.com ``` ## 3. Or, git clone and install: ``` git clone --depth 1 https://github.com/acmesh-official/acme.sh.git cd acme.sh ./acme.sh --install -m my@example.com ``` ## 4. Advanced installation ``` git clone --depth 1 https://github.com/acmesh-official/acme.sh.git cd acme.sh ./acme.sh --install \ --home ~/myacme \ --config-home ~/myacme/data \ --cert-home ~/mycerts \ --accountemail "my@example.com" \ --accountkey ~/myaccount.key \ --accountconf ~/myaccount.conf \ --useragent "this is my client." ``` You don't need to set them all, just set those ones you care about. Explanations : - `--home` is a customized dir to install `acme.sh` in. By default, it installs into `~/.acme.sh` - `--config-home` is a writable folder, acme.sh will write all the files(including cert/keys, configs) there. By default, it's in `--home` - `--cert-home` is a customized dir to save the certs you issue. By default, it's saved in `--config-home`. - `--accountemail` is the email used to register an account to Let's Encrypt, you will receive a renewal notice email here. - `--accountkey` is the file saving your account private key. By default, it's saved in `--config-home`. - `--useragent` is the user-agent header value used to send to Let's Encrypt. - `--nocron` install acme.sh without cronjob ## 5. Special case: Converting LE account data from certbot to acme.sh If already using certbot, then there is the possibility to convert its LE account data to acme.sh format. See https://github.com/maddes-b/linux-stuff/tree/main/acme.sh . If re-using the LE account created from certbot, then it is recommended **not** to specify `-m/--email` during installation. acme.sh-0.0~git20250417.7502af3/How-to-issue-a-cert.md000066400000000000000000000073051500024665000214050ustar00rootroot00000000000000### 1. Single domain: #### 1) Webroot mode: If you already have a web server running, you should use webroot mode. you only need write access to the web root folder. ```sh acme.sh --issue -d example.com -w /home/wwwroot/example.com ``` #### 2) Standalone mode: If you don't have a web server, maybe you are on a smtp or ftp server, the 80 port is free. you can use standalone mode. acme.sh has a builtin standalone webserver, it can listen at 80 port to issue the cert. ```sh acme.sh --issue -d example.com --standalone ``` If you are using a non-standard `80` port behind a reverse proxy or load balancer , you can use `--httpport` to specify your port: ```sh acme.sh --issue -d example.com --standalone --httpport 88 ``` #### 3) Standalone tls alpn mode: If you don't have a web server, maybe you are on a smtp or ftp server, the `443` port is free. you can use standalone tls alpn mode. acme.sh has a builtin standalone tls webserver, it can listen at 443 port to issue the cert. ```sh acme.sh --issue -d example.com --alpn ``` If you are using a non-standard `443` port behind a reverse proxy or load balancer , you can use `--tlsport` to specify your port: ```sh acme.sh --issue -d example.com --alpn --tlsport 8443 ``` #### 4) DNS API mode: Yes, if your nameservice provider has an api, we can use the api to automatically add the txt record for you. your cert will be automatically issued and renewed. Cloudflare api: ```sh export CF_Token="sdfsdfsdfljlbjkljlkjsdfoiwje" export CF_Email="xxxx@sss.com" acme.sh --issue -d example.com --dns dns_cf ``` How to use dns api: https://github.com/acmesh-official/acme.sh/wiki/dnsapi #### 5) DNS manual mode: See: https://github.com/acmesh-official/acme.sh/wiki/DNS-manual-mode #### 6) DNS alias mode: See: https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode #### 7) Apache mode: If your website is running apache server, acme.sh can use apache server to issue cert. And acme.sh will restore your apache conf after the cert is issued, don't worry. ```sh acme.sh --issue -d example.com --apache ``` #### 8) Nginx mode: If your website is running nginx server, acme.sh can use nginx server to issue cert. And acme.sh will restore your nginx conf after the cert is issued, don't worry. ``` acme.sh --issue -d example.com --nginx ``` Sometimes, nginx conf file can not be found automatically, you can specify one: ``` acme.sh --issue -d example.com --nginx /etc/nginx/nginx.conf ``` You can also specify the website conf: ``` acme.sh --issue -d example.com --nginx /etc/nginx/conf.d/example.com.conf ``` ### 2. Multiple domains, SAN mode Issue a single cert including multiple domains. All the domains use the same validation method: #### 1) Webroot mode: You must point `example.com` and `www.example.com` to the same web root folder `/home/wwwroot/example.com` ``` acme.sh --issue -d example.com -w /home/wwwroot/example.com -d www.example.com ``` #### 2) Standalone mode: ``` acme.sh --issue -d example.com --standalone -d www.example.com ``` #### 3) Dns api mode: Cloud flare api: ``` export CF_Token="sdfsdfsdfljlbjkljlkjsdfoiwje" export CF_Email="xxxx@example.com" acme.sh --issue -d example.com --dns dns_cf -d www.example.com ``` #### 4) Dns manual mode: ``` acme.sh --issue -d example.com --dns -d www.example.com ``` ### 3. Multiple domains, SAN mode, Hybrid mode Issue a single cert including multiple domains. Each domain uses a different validation method. ``` acme.sh --issue \ -d aa.com -w /home/wwwroot/aa.com \ -d bb.com --dns dns_cf \ -d cc.com --apache \ -d dd.com -w /home/wwwroot/dd.com ``` ``` acme.sh --issue \ -d aa.com --dns dns_dp \ -d bb.com --dns dns_cf \ -d cc.com --dns dns_ns ``` acme.sh-0.0~git20250417.7502af3/How-to-run-on-DD-WRT-with-lighttpd.md000066400000000000000000000146231500024665000240500ustar00rootroot00000000000000This guide is written for a Kong build of DD-WRT, but should work with any that has access to lighttpd. You will need a JFFS partition and need to use command line tools via ssh/telnet. 1. **Install opkg and get CA certificates.** To install opkg, you need a /opt partition. The easiest way (and totally adequate for the goal of running lighttpd) is to mount /opt from a jffs partition, which is what we do here. First, enable JFFS from Administration->Management. The first time you use it you'll want to check the box to Clean internal flash storage. Once it's running (you may need to reboot), use a terminal to `mkdir /jffs/opt`, and mount it to the /opt directory using `mount --bind /jffs/opt /opt`. This line will also need to go into your startup script under Administration->Commands. Second, install opkg - either by running `bootstrap`, or (preferred if you need more apps) by [installing entware](https://www.dd-wrt.com/wiki/index.php/Installing_Entware). Third, install CA certificates which permit use of HTTPS from DD-WRT, as well as the networking tool socat. Run `opkg update; opkg install ca-certificates socat`. Certificates are installed into `/opt/etc/ssl/certs`. 2. **Install acme.sh onto the JFFS.** Somewhat arbitrarily, I chose to put it, and related configuration, in `/jffs/usr/ssl`. To do this: ```bash mkdir /jffs/usr mkdir /jffs/usr/ssl cd /jffs/usr/ssl curl --capath /opt/etc/ssl/certs https://raw.githubusercontent.com/Neilpang/acme.sh/master/acme.sh > acme.sh chmod a+x acme.sh ``` Note that curl is using your newly installed root certificates to get acme.sh, as acme.sh will do to get your TLS certificates. 3. **Get a trusted certificate issued from LetsEncrypt.org for your domain(s).** In order to do this they need to authenticate that you control the domain in question. The simplest general way at present is to use a TLS an HTTP service run by acme.sh. [The TLS method is not currently supported by LetsEncrypt](https://community.letsencrypt.org/t/important-what-you-need-to-know-about-tls-sni-validation-issues/50811), so we need to use the HTTP port (80). This requires temporarily stopping the DD-WRT gui server and opening up the HTTP port on the firewall (assuming it's not already open). Alternatively, DNS approaches could be better if your DNS provider is supported. Refer to the acme.sh documentation for other approaches or more compliifcated domain setups. Finally, [lighttpd authentication may be supported in future](https://github.com/Neilpang/acme.sh/issues/687). To issue yourself a certificate for the domain assigned to dd-wrt, using a temporary HTTP server: ```bash ./acme.sh --issue --standalone -d [ddwrtdomain] \ --home /jffs/usr/ssl --ca-path /opt/etc/ssl/certs \ --pre-hook "stopservice httpd && iptables -I INPUT -p tcp --dport http -j ACCEPT" \ --post-hook "startservice httpd && iptables -D INPUT -p tcp --dport http -j ACCEPT" ``` Note: **Be sure to replace [ddwrtdomain] with your domain name.** To test your configuration, always add the `--test` parameter, to avoid being locked out by letsencrypt. Note also that we're assuming that it is httpd, not lighttpd that is serving http requests by default (otherwise stopservice/startservice lighttpd, not httpd, and remove that command from step 5; you will also need to manually restart lighttpd once after that step to effectuate changes). If you use a complicated firewall setup, you may need to modify the iptables commands to open the http port. Finally, note that letsencrypt will not issue certificates for certain "public domains" which are not registered as such. In particular, this currently precludes the 85,000 domains served by `freedns.afraid.org` from being issued certificates. 4. **Configure lighttpd to use the certificates provided by acme/letsencrypt.** To do this you will need to modify the default lighttpd.conf used by DD-WRT. The simplest way to do this is to copy the default configuration to /jffs/etc (`mkdir /jffs/etc; cp /tmp/lighttpd.conf /jffs/etc`), and then modify it (placed in that directory, it will override the default settings). Then modify /jffs/etc/lighttpd.conf (using [vi](http://www.mcsr.olemiss.edu/seminars/BASIC%20VI%20TUTORIAL.pdf)), so that the SSL section looks like this: ``` $SERVER["socket"] == ":443" { ssl.engine = "enable" ssl.pemfile = "/jffs/etc/lighttpd_ssl/hostkey.pem" ssl.ca-file = "/jffs/etc/lighttpd_ssl/fullchain.crt" } ``` If you want to just run an HTTPS server, without any HTTP server, you can simply put a `#` in front of the first and last lines there and change the server.port line to `server.port = 443`. Do not remove your HTTP port from the web GUI, as this will cause lighttpd to malfunction. 5. **Install your new certificates to the place lighttpd will find them.** ```bash ./acme.sh --install-cert -d [ddwrtdomain] --home /jffs/usr/ssl \ --cert-file /jffs/etc/lighttpd_ssl/host.crt \ --key-file /jffs/etc/lighttpd_ssl/host.key \ --fullchain-file /jffs/etc/lighttpd_ssl/fullchain.crt \ --reloadcmd "cat /jffs/etc/lighttpd_ssl/host.crt /jffs/etc/lighttpd_ssl/host.key > /jffs/etc/lighttpd_ssl/hostkey.pem; stopservice lighttpd; startservice lighttpd" ``` Again, **replace [ddwrtdomain] with your domain name.** Lighttpd wants the SSL certificate and key in the same file; we use the reloadcmd to place them there and restart lighttpd. We use pre- and post- hooks to restart httpd; these commands are necessary so that they will function properly when run from cron. 6. **Set up a cron job to update certificate automatically before it expires.** Under Administration/Management, add a line under Additional Cron Jobs: ``` # sundays @4:05am, renew/install SSL certificates if necessary (restarting httpd & lighttpd in that case) 5 4 * * 0 root /jffs/usr/ssl/acme.sh --cron --home /jffs/usr/ssl >>/jffs/usr/ssl/cron.log 2>&1 ``` It will only stop/restart lighttpd if a certificate may need to be re-issued, and will automatically issue and install it according to the settings you used in steps 3 and 5 above. LetsEncrypt recommends running daily although this script only runs weekly (since LetsEncrypt certs currently last 90 days and will renew at most every 60, I don't see why it needs to run daily). Voila! Your server is using a trusted certificate that will auto-renew.acme.sh-0.0~git20250417.7502af3/How-to-run-on-OpenWrt.md000066400000000000000000000026741500024665000217220ustar00rootroot00000000000000**See [OpenWrt Wiki: Get a free HTTPS certificate from LetsEncrypt for OpenWrt with ACME.sh](https://openwrt.org/docs/guide-user/services/tls/acmesh)** Setup and run acme.sh on your [OpenWrt](https://openwrt.org) router and have HTTPS secured management. ### Step 1: Install packages `opkg install luci-ssl-openssl acme luci-app-acme` If you want to use DNS-based certificate verification, also install the DNS providers: `opkg install acme-acmesh-dnsapi` ### Step 2: Configure Web Server Here we'll tell uhttpd redirect to HTTPS. These commands use the OpenWrt [`uci` command](https://wiki.openwrt.org/doc/uci), a brilliant way to parse, get, set, and edit values and sections from config files. It makes scripting OpenWrt a breeze. ``` uci set uhttpd.main.redirect_https=1 uci commit uhttpd /etc/init.d/uhttpd restart ``` ### Step 3: Configure acme.sh and get your certificate On your router: Navigate to `Services -> ACME certs` in LuCI and configure your certificate details. Make sure you made it `Enabled` for your configured certificate. For old versions you may also need to select `Use for uhttpd`. This option was removed in newer versions and all dependant services must setup their own hotplug hook scripts to restart themselves. If you prefer to use the command line, simply edit `/etc/config/acme`, and run `/etc/init.d/acme start` afterwards. ### Step 4: Configure Firewall Open or forward LuCI port for external access. (use Webinterface) acme.sh-0.0~git20250417.7502af3/How-to-use-Amazon-Route53-API.md000066400000000000000000000042411500024665000227720ustar00rootroot000000000000001. Follow http://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html to create a new user and obtain API keys 2. Save the downloaded API keys to later use with acme.sh 3. In the user profile, click in Permissions, followed by Add Permissions 4. Then click the 3rd icon "Attach existing policies directly" 5. Click "Create Policy" and in the new window choose "Create Your Own Policy" 6. Enter a name to your policy and paste the following ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "route53:GetHostedZone", "route53:ListHostedZones", "route53:ListHostedZonesByName", "route53:GetHostedZoneCount", "route53:ChangeResourceRecordSets", "route53:ListResourceRecordSets" ], "Resource": "*" } ] } ``` Validate the policy and Click Create. Apply the new policy to your new user. You can now use the new API keys with acme.sh [https://github.com/Neilpang/acme.sh/tree/master/dnsapi#10-use-amazon-route53-domain-api](https://github.com/Neilpang/acme.sh/tree/master/dnsapi#10-use-amazon-route53-domain-api) ### appendix If you want to use a much more restrictive AWS policy, use the following: - http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/access-control-managing-permissions.html ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "route53:ListHostedZones" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "route53:GetHostedZone", "route53:ListResourceRecordSets" ], "Resource": "arn:aws:route53:::hostedzone/" }, { "Effect": "Allow", "Action": "route53:ChangeResourceRecordSets", "Resource": "arn:aws:route53:::hostedzone/", "Condition": { "ForAllValues:StringEquals": { "route53:ChangeResourceRecordSetsNormalizedRecordNames": "_acme-challenge..." } } } ] } ``` acme.sh-0.0~git20250417.7502af3/How-to-use-Azure-DNS.md000066400000000000000000000176631500024665000214160ustar00rootroot00000000000000#### Prerequisites You need the Azure CLI 2.0 tools to create a service principal for access to your DNS Zone. Either install Azure CLI 2.0 locally or use the Azure Cloud Shell in Bash mode. (See the [ Azure Command-Line Interface (CLI) documentation](https://learn.microsoft.com/en-us/cli/azure/?view=azure-cli-latest) for more details) #### Log-in to Azure (Not required when using the Azure Cloud Shell) ``` az login ``` ```json [ { "cloudName": "AzureCloud", "id": "12345678-9abc-def0-1234-567890abcdef", "isDefault": true, "name": "myAzureSubscription", "state": "Enabled", "tenantId": "11111111-2222-3333-4444-555555555555", "user": { "name": "someone@example.com", "type": "user" } } ] ``` #### Set your Azure subscription if you have more than one ``` az account list ``` ```json [ { "cloudName": "AzureCloud", "homeTenantId": "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa", "id": "baaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa", "isDefault": true, "managedByTenants": [], "name": "Subscription A", "state": "Enabled", "tenantId": "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa", "user": { "cloudShellID": true, "name": "email@example.com", "type": "user" } }, { "cloudName": "AzureCloud", "homeTenantId": "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa", "id": "caaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa", "isDefault": false, "managedByTenants": [], "name": "Subscription B", "state": "Enabled", "tenantId": "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa", "user": { "cloudShellID": true, "name": "email@example.com", "type": "user" } } ] ``` ``` az account set --subscription "Subscription B" ``` #### List your DNS Zones ``` az network dns zone list ``` ```json [ { "etag": "00000002-0000-0000-f641-73c64955d301", "id": "/subscriptions/12345678-9abc-def0-1234-567890abcdef/resourceGroups/exampledns_rg/providers/Microsoft.Network/dnszones/example.com", "location": "global", "maxNumberOfRecordSets": 5000, "name": "example.com", "nameServers": [ "ns1-02.azure-dns.com.", "ns2-02.azure-dns.net.", "ns3-02.azure-dns.org.", "ns4-02.azure-dns.info." ], "numberOfRecordSets": 11, "resourceGroup": "exampledns_rg", "tags": {}, "type": "Microsoft.Network/dnszones" } ] ``` #### Create a service principal The service principal is used to grant acme.sh access to the DNS Zone using the id value from the previous commands output (See the [az ad sp create-for-rbac](https://learn.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest#az-ad-sp-create-for-rbac) documentation for more details) ``` az ad sp create-for-rbac --name "AcmeDnsValidator" --role "DNS Zone Contributor" --scopes \ /subscriptions/12345678-9abc-def0-1234-567890abcdef/resourceGroups/exampledns_rg/providers/Microsoft.Network/dnszones/example.com ``` ```json { "appId": "3b5033b5-7a66-43a5-b3b9-a36b9e7c25ed", "displayName": "AcmeDnsValidator", "name": "http://AcmeDnsValidator", "password": "e.L8Q~4jGhWHheCKjdRzw3gyBBwOmrTyYF9NYbxs", "tenant": "11111111-2222-3333-4444-555555555555" } ``` ##### Note: Dealing with multiple DNS Zones If you are managing certificates for multiple DNS Zones, you can create the service principal with multiple scopes. For example, if you are managing certificates for both `example.com` and `example.edu`, you can create the service principal with both scopes: ``` az ad sp create-for-rbac --name "AcmeDnsValidator" --role "DNS Zone Contributor" --scopes \ /subscriptions/12345678-9abc-def0-1234-567890abcdef/resourceGroups/exampledns_rg/providers/Microsoft.Network/dnszones/example.com \ /subscriptions/12345678-9abc-def0-1234-567890abcdef/resourceGroups/exampledns2_rg/providers/Microsoft.Network/dnszones/example.edu ``` Or if the service principal has already been created, you can grant it access to the additional scope: ``` az ad sp list --filter "displayname eq 'AcmeDnsValidator'" | grep '^ \"id\":' ``` (The `grep` above is assuming a json array of nested lists is returned with a tab size of two spaces and is finding the top-level `id`) ```json "id": "daaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa", ``` ``` az role assignment create --assignee daaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa --role "DNS Zone Contributor" --scope \ /subscriptions/12345678-9abc-def0-1234-567890abcdef/resourceGroups/deleteme_rg/providers/Microsoft.Network/dnszones/example.edu ``` ##### Note: Dealing with multiple credentials By default acme.sh saves credentials in `~/.acme.sh/account.conf` and these credentials are used for all DNS zones. If you want to use different credentials, use the `--accountconf` switch to specify a configuration file. #### Limit access permissions to TXT records In Azure DNS you can limit the permissions for the service principal further and only grant permissions to modifiy TXT records for a given DNS Zone. (See [How to protect DNS zones and records](https://learn.microsoft.com/en-us/azure/dns/dns-protect-zones-recordsets) for more details) Example: * Azure Subscription is `12345678-9abc-def0-1234-567890abcdef` * The resource group of your DNS Zone is `exampledns_rg` * The DNS Zone is `example.com` ```sh #!/usr/bin/env sh # Create a custom RBAC role that grants permissions to modify only TXT records dnscustomrole='{ "Name": "DNS TXT Contributor", "Id": "", "IsCustom": true, "Description": "Can manage DNS TXT records only.", "Actions": [ "Microsoft.Network/dnsZones/TXT/*", "Microsoft.Network/dnsZones/read", "Microsoft.Authorization/*/read", "Microsoft.Insights/alertRules/*", "Microsoft.ResourceHealth/availabilityStatuses/read", "Microsoft.Resources/deployments/read", "Microsoft.Resources/subscriptions/resourceGroups/read" ], "NotActions": [ ], "AssignableScopes": [ "/subscriptions/12345678-9abc-def0-1234-567890abcdef" ] }' az role definition create --role-definition "$dnscustomrole" # Create a new service principal and grant permissions to modify TXT recornds in the give DNS Zone az ad sp create-for-rbac --name "AcmeDnsValidator" --role "DNS TXT Contributor" --scopes "/subscriptions/12345678-9abc-def0-1234-567890abcdef/resourceGroups/exampledns_rg/providers/Microsoft.Network/dnszones/example.com" # or grant an existing service principal permissions to modify TXT recornds in the give DNS Zone #az role assignment create --assignee 3b5033b5-7a66-43a5-b3b9-a36b9e7c25ed --scope "/subscriptions/12345678-9abc-def0-1234-567890abcdef/resourceGroups/exampledns_rg/providers/Microsoft.Network/dnszones/example.com" --role "DNS TXT Contributor" ``` #### You can now use acme.sh ``` export AZUREDNS_SUBSCRIPTIONID="12345678-9abc-def0-1234-567890abcdef" export AZUREDNS_TENANTID="11111111-2222-3333-4444-555555555555" export AZUREDNS_APPID="3b5033b5-7a66-43a5-b3b9-a36b9e7c25ed" # appid of the service principal export AZUREDNS_CLIENTSECRET="e.L8Q~4jGhWHheCKjdRzw3gyBBwOmrTyYF9NYbxs" # password from creating the service principal acme.sh --issue --dns dns_azure -d example.com -d www.example.com ``` #### Update service principal password The service principal credentials may eventually expire. Some acme.sh renewal errors that are signs of the credentials expiring: - `no acccess token received. Check your Azure settings` - `access denied make sure your Azure settings are correct` ``` az ad sp list --filter "displayname eq 'AcmeDnsValidator'" | grep '^ \"id\":' ``` (The `grep` above is assuming a json array of nested lists is returned with a tab size of two spaces and is finding the top-level `id`) ```json "id": "daaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa", ``` ``` az ad sp credential reset --id daaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa ``` Update `~/.acme.sh/account.conf` with the new credentials. (See [az ad sp credential](https://learn.microsoft.com/en-us/cli/azure/ad/sp/credential?view=azure-cli-latest#az-ad-sp-credential-reset) for details)acme.sh-0.0~git20250417.7502af3/How-to-use-OVH-domain-api.md000066400000000000000000000111571500024665000223460ustar00rootroot00000000000000# Quick Start ## 1. Create application key and secret ### Option 1 https://eu.api.ovh.com/createApp/ Watch out the acme.sh output and copy/paste the validation URL. See [Step 3](https://github.com/acmesh-official/acme.sh/wiki/How-to-use-OVH-domain-api#3-authentication-the-api-key) ### Option 2 If you already have created an application and know its secret (application secret) open the link https://www.ovh.com/auth/api/createToken and use hereafter settings * GET /auth/time * GET /domain * GET /domain/zone/* * GET /domain/zone/*/record * POST /domain/zone/*/record * POST /domain/zone/*/refresh * PUT /domain/zone/\*/record/\* * DELETE /domain/zone/\*/record/\* ## 2. Set api key and api secret. ``` # application key export OVH_AK="your application key" # application secret export OVH_AS="your application secret" # consumer key export OVH_CK="your consumer key" acme.sh --issue -d mydomain.com --dns dns_ovh --server letsencrypt ``` If you are first time using OVH api, you are required to authenticate the api. (This only happens the first time.) You will see some thing like bellow: ``` [Thu, Aug 25, 2016 10:54:03] Using OVH endpoint: ovh-eu [Thu, Aug 25, 2016 10:54:04] OVH consumer key is empty, Let's get one: [Thu, Aug 25, 2016 10:54:05] Please open this link to do authentication: https://eu.api.ovh.com/auth/?credentialToken=n0Qbjm6wBdBr2KiSqIuYSEnixxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [Thu, Aug 25, 2016 10:54:05] Here is a guide for you: https://github.com/Neilpang/acme.sh/wiki/How-to-use-OVH-domain-api [Thu, Aug 25, 2016 10:54:05] Please retry after the authentication is done. [Thu, Aug 25, 2016 10:54:05] Error add txt for domain:_acme-challenge.mytest.mydomain.com ``` ## 3. Authentication the api key. (This only happens the first time.) Open the link above: ``` https://eu.api.ovh.com/auth/?credentialToken=n0Qbjm6wBdBr2KiSqIuYSEnixxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ``` In the page, please select "Unlimited" for the Validity. Click "Authorize Access" ## 4. Then go back to try again. ``` acme.sh --issue -d mydomain.com --dns dns_ovh --server letsencrypt ``` Done. ## 5. OVH api support OVH, Kimsufi, SoYouStart. The default is using `ovh-eu` region. If you are using ovh-ca region, Create app key here: https://ca.api.ovh.com/createApp/ Then please specify the region in the first step: ``` export OVH_END_POINT=ovh-ca export OVH_AK="your application key" export OVH_AS="your application secret" acme.sh --issue -d mydomain.com --dns dns_ovh --server letsencrypt ``` All the supported regions: * `ovh-eu` default * `ovh-us` * `ovh-ca` * `kimsufi-eu` * `kimsufi-ca` * `soyoustart-eu` * `soyoustart-ca` If your region is not specified then you can specify a full API URL like: `export OVH_END_POINT="https://eu.api.ovh.com/1.0"` # Advanced Usage ## 1. Create application key, secret and consumer - **OVH Europe**: `https://api.ovh.com/createToken/?GET=/domain/zone/*&POST=/domain/zone/*&PUT=/domain/zone/*&DELETE=/domain/zone/*/record/*` - **OVH USA**: `https://api.us.ovhcloud.com/createToken/?GET=/domain/zone/*&POST=/domain/zone/*&PUT=/domain/zone/*&DELETE=/domain/zone/*/record/*` - **OVH Canada**: `https://ca.api.ovh.com/createToken/?GET=/domain/zone/*&POST=/domain/zone/*&PUT=/domain/zone/*&DELETE=/domain/zone/*/record/*` In the page, please select "Unlimited" for the Validity. ## 2. Profite! ``` # Credentials export OVH_AK="your application key" export OVH_AS="your application secret" export OVH_CK="your consumer key" # Generate your certificate acme.sh --issue -d mydomain.com --dns dns_ovh --server letsencrypt ``` # Security It is a good security practice to limit what a given API key can in the event it is lost, stolen or anything wrong happens to limit the potential damages. OVH API keys can be limited to a specific domain zone using a simple pattern mechanism. For example, to restrict an OVH API key to manage "mydomain.com", you may use the following settings. Of course this can easily be customized to support any or multiple domains: - **OVH Europe**: `https://api.ovh.com/createToken/?GET=/domain/zone/mydomain.com/*&POST=/domain/zone/mydomain.com/*&PUT=/domain/zone/mydomain.com/*&GET=/domain/zone/mydomain.com&DELETE=/domain/zone/mydomain.com/record/*` - **OVH USA**: `https://api.us.ovhcloud.com/createToken/?GET=/domain/zone/mydomain.com/*&POST=/domain/zone/mydomain.com/*&PUT=/domain/zone/mydomain.com/*&GET=/domain/zone/mydomain.com&DELETE=/domain/zone/mydomain.com/record/*` - **OVH Europe**: `https://api.ovh.com/createToken/?GET=/domain/zone/mydomain.com/*&POST=/domain/zone/mydomain.com/*&PUT=/domain/zone/mydomain.com/*&GET=/domain/zone/mydomain.com&DELETE=/domain/zone/mydomain.com/record/*` acme.sh-0.0~git20250417.7502af3/How-to-use-Oracle-Cloud-Infrastructure-DNS.md000066400000000000000000000120671500024665000256100ustar00rootroot00000000000000The Oracle Cloud Infrastructure (OCI) DNS service lets you [create and manage public and private DNS zones][DNS] in an OCI tenancy. The DNS Service provides each tenancy with a limit of 1,000 zones and 25,000 records per zone and is [charged per 1M queries][COST]. Before you can use OCI DNS with `acme.sh`, you'll need the following: * A private [API signing key][APIKEY]; and * The [tenancy and service account OCIDs][OCIDS] We recommend [installing the OCI CLI][CLI] and using the [interactive setup process][CSTP] to create an API signing keypair. If the OCI CLI is configured, the plugin will automatically detect and use the configuration file for authentication. Alternatively, the [OCI Developer Guide][DG] provides the manual steps required to generate the API signing keys and determine the required OCIDs. ## Configuration ### Automatic configuration **No configuration is required** if an [OCI CLI][CLI] configuraton file is located at `$HOME/.oci/config` and has a `DEFAULT` profile that can be used to manage DNS records in the target tenancy. To override the configuration file path or profile name, set the following environment variables: * `OCI_CLI_CONFIG_FILE`: set to the full path including filename of the OCI SDK and CLI configuration file. * `OCI_CLI_PROFILE`: provide an existing profile from the configuration file. Case-sensitive! ### Manual configuration If the OCI CLI is not installed, the following environment variables must be set: * `OCI_CLI_USER`: OCID of the user calling the API. Example: `ocid1.user.oc1..` * `OCI_CLI_TENANCY`: OCID of your tenancy. Example: `ocid1.tenancy.oc1..` * `OCI_CLI_REGION`: Your Oracle Cloud Infrastructure home region. You also need to provide the API signing key using one of the following two variables: * `OCI_CLI_KEY_FILE`: Path to the file containing the private API signing key in PEM format; or * `OCI_CLI_KEY`: the private API signing key in PEM format > **Tip:** The variables above can also be used to override the values stored in the > OCI SDK and CLI configuration file. ### Issuing a certificate To issue a certificate, ensure either the OCI CLI is working correctly or all the mandatory environment variables have been configured, then run: ```shell acme.sh --issue --dns dns_oci -d example.com -d www.example.com ``` To issue a wildcard certificate, use:: ```shell acme.sh --issue --dns dns_oci -d example.com -d *.example.com ``` ## Required IAM service policy Permissions are required to add and remove DNS records from DNS. Ensure that a policy exists that grants the specified user sufficient permission to create and remove `TXT` records in the target zone(s) in the tenancy. Here is an example policy that grants all DNS operations in all zones in the tenancy for all members of a specific user group: ``` Allow group to manage dns in tenancy ``` If you're new to policies, see [Getting Started with Policies][POLS] and [Common Policies][CPOLS]. For more details about policies for DNS, see [Details for the DNS Service][DNSPOL]. ## Security recommendations The **[Oracle Cloud Infrastructure Security Guide][OSG]** details the recommended **[best practices for securing user authentication][BP]** which include: * creating **a dedicated service user account** specifically for GitHub Actions; * assigning that service account a **unique** and **complex** password; * **rotating the API signing key pair** used by the service account every 90 days; and * using **[GitHub encrypted secrets][GHS]** to store credentials. ## Reporting an issue Please use to report any issues or bugs. [DNS]: https://docs.oracle.com/en-us/iaas/Content/DNS/Tasks/managingdnszones.htm#Managing_DNS_Service_Zones [COST]: https://www.oracle.com/cloud/price-list.html#dns [DG]: https://docs.oracle.com/en-us/iaas/Content/API/Concepts/devtoolslanding.htm [APIKEY]: https://docs.oracle.com/en-us/iaas/Content/API/Concepts/apisigningkey.htm [OCIDS]: https://docs.oracle.com/en-us/iaas/Content/API/Concepts/apisigningkey.htm#five [CLI]: https://docs.oracle.com/en-us/iaas/Content/API/Concepts/cliconcepts.htm [CSTP]:https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm#configfile [OSG]: https://docs.oracle.com/en-us/iaas/Content/Security/Concepts/security_guide.htm [BP]: https://docs.oracle.com/en-us/iaas/Content/Security/Reference/iam_security.htm [GHS]: https://docs.github.com/en/actions/reference/encrypted-secrets [REGS]: https://docs.oracle.com/en-us/iaas/Content/General/Concepts/regions.htm#top [CLIVARS]: https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/clienvironmentvariables.htm [IAM]: https://docs.oracle.com/en-us/iaas/Content/DNS/Concepts/dnszonemanagement.htm#Required_IAM_Service_Policy [POLS]: https://docs.oracle.com/en-us/iaas/Content/Identity/Concepts/policygetstarted.htm#Getting_Started_with_Policies [CPOLS]: https://docs.oracle.com/en-us/iaas/Content/Identity/Concepts/commonpolicies.htm#top [DNSPOL]: https://docs.oracle.com/en-us/iaas/Content/Identity/Reference/dnspolicyreference.htm#Details_for_the_DNS_Serviceacme.sh-0.0~git20250417.7502af3/How-to-use-lexicon-DNS-API.md000066400000000000000000000062731500024665000223730ustar00rootroot00000000000000## lexicon is a python tool for a number of dns providers. As I'm writing this doc, it supports the following dns api: The current supported providers are: * Cloudflare * DigitalOcean * DNSimple * DnsMadeEasy * DNSPark * EasyDNS * Namesilo * NS1 * PointHQ * Rage4 * TransIP * Vultr You can check its project page: https://github.com/AnalogJ/lexicon You must install `python` and `lexicon` before using it. For more examples, please check lexicon page: https://github.com/AnalogJ/lexicon ## Examples: ### 1. Using lexicon cloudflare api: ``` export PROVIDER=cloudflare export LEXICON_CLOUDFLARE_USERNAME="xxxx@xxx.com" export LEXICON_CLOUDFLARE_TOKEN="XXXXXXXXXXXXXXX" acme.sh --issue -d test.acme.sh --dns dns_lexicon ``` ### 2. Using lexicon namesilo api: [Namesilo](https://www.namesilo.com/) applies any submitted changes to DNS records **every 15 minutes**. To make sure verification aligns with propagation, `--dnssleep` must be set for **16 minutes (960 seconds)**. You may generate a new API key (namesilo-api-token) at the [api manager](https://www.namesilo.com/account_api.php) under *Account Options* after logging in. ``` export PROVIDER=namesilo export LEXICON_NAMESILO_TOKEN="namesilo-api-token" acme.sh --issue -d test.acme.sh --dns dns_lexicon --dnssleep 960 ``` ### 3. Using lexicon TransIP api: ``` export PROVIDER=TRANSIP export LEXICON_TRANSIP_USERNAME="username" export LEXICON_TRANSIP_API_KEY="/path/to/file.key" acme.sh --issue -d test.acme.sh --dns dns_lexicon ``` ### 4. Using Technitium DNS via Lexicon `ddns` API: In this example, we request a DNS-01-challenged ACME certificate using a custom (internal) ACME server via the Lexicon API via [Technitium DNS](https://technitium.com/dns/). Note that we use `--dnssleep 0` to skip the public DNS check (since this is for an internal DNS setup). There are some prerequisites to setup TSIG within Technitium. In Technitium's Web UI: * Create a TSIG Key via Settings>TSIG. Set ``, ``, and optionally `` (if you don't set Shared Secret, Technitium will create one for you when you click "Save"). For example: * KeyName: `lexicon` * SharedSecret: `12345abcde` (NOTE: this is just an example!) * Algorithm: `HMAC-SHA256` * Enable Zone Transfer and Dynamic Updates at Zones > `example.com` > Options > Zone Options. * [Zone Transfer tab] Zone Transfer: `Allow` * [Zone Transfer tab] Zone Transfer TSIG Key Names: `` from above - optionally you can select your KeyName from "Quick Add" menu * [Dynamic Updates tab] Dynamic Updates: `Allow` (use "Specified IP Addresses" if possible) * [Dynamic Updates tab] Add a security policy with the following options: * TSIG Key Name: `` * Domain Name: `*.example.com` * Allowed Record Types: `TXT` In your `acme.sh` CLI session: ``` export PROVIDER=ddns # Format: export LEXICON_DDNS_DDNS_SERVER= export LEXICON_DDNS_DDNS_SERVER=10.1.0.5 # Format: export LEXICON_DDNS_TOKEN=:: export LEXICON_DDNS_TOKEN=hmac-sha256:lexicon:12345abcde acme.sh --issue \ -d test.example.com \ --dns dns_lexicon \ --server https://hcv.ff.lan/v1/pki_int/acme/directory \ --dnssleep 0 ```acme.sh-0.0~git20250417.7502af3/How-to-use-on-Solaris-based-operating-sytsems.md000066400000000000000000000031651500024665000264730ustar00rootroot00000000000000I ran this on Illumos, with Apache22 ## 1. get acme.sh [Install acme.sh](How-to-install) ## 2. Make sure you have wget and GNU sed installed ``` pkg install gnu-sed wget ``` ## 3. Set up your environment * your path needs to include GNU sed before "Sun" sed, and include the path to "apachectl" * you need to set "ACME_DIR" to be somewhere at least chmod 755 readable by the Apache web server (i.e. don't use /root/acme because the /root directory is not read/exec by "other". The default ACME_DIR is set to be the automounted "/home/.acme" directory. (Neil suggests possibly using /tmp/.acme) ``` export PATH ; PATH=/usr/gnu/bin:/usr/bin:/usr/sbin:/sbin:/usr/apache2/2.2/bin export ACME_DIR ; ACME_DIR=/tmp/.acme ``` ## 4. Run the acme.sh * Please don't specify the "-w" option, this will only cause confusion * if you are using Proxy forwarding, like I was, or any other similar configuration; you will need to modify the Apache configuration to allow "/.well-known" to pass through * I never had any luck with curl, so I force the use of wget. YMMV * if you are going to play with this a lot, you will want to add "--test" to the command, which will use the "staging area" of letencrypt.com, and/or --debug to check that it is working. If you do use the "staging area"; when you come to do this for real you will need to add "--force" to the command ``` ./acme.sh --issue --apache -d online.domain.com --use-wget ``` ## 5. adding to cron the simple command to add this to cron is: ``` ./acme.sh --install-cronjob ``` however you might well need to copy/move the "acme.sh" command into ~/.acme.sh for this to pick up the location correctly.acme.sh-0.0~git20250417.7502af3/How-to-use-on-embedded-FreeBSD.md000066400000000000000000000053211500024665000232450ustar00rootroot00000000000000FreeBSD embedded systems like nas4free, FreeNAS etc. usually don't have curl and wget installed. The [fetch(1)](http://www.freebsd.org/cgi/man.cgi?fetch(1)) utility can't replace them, because it doesn't support POST and PUT requests. So I used this workaround to get curl running on this platform. Full story in Issue [#194](https://github.com/Neilpang/acme.sh/issues/194). ## Requirements You need: * a persistent storage (to save some files) * your FreeBSD version and architecture (e.g. FreeBSD 10, x86-64) ## 1. Find curl and ca-root-nss packages You need to get the curl binary and the ca-root-nss.crt containing trusted certificate authorities. Search for the packages in the download archives: [http://distcache.freebsd.org/](http://distcache.freebsd.org/) E.g., currently these would be for FreeBSD 10 x86-64: * http://distcache.freebsd.org/freebsd:10:x86:64/latest/All/curl-7.49.0.txz * http://distcache.freebsd.org/freebsd:10:x86:64/latest/All/ca_root_nss-3.22.2.txz ## 2. Download and extract Replace the URLs found in step 1 above. ``` $ cd # e.g. nas4free: somewhere in /mnt/pool0 $ fetch -o curl.txz http://distcache.freebsd.org/freebsd:10:x86:64/latest/All/curl-7.49.0.txz $ tar xvf curl.txz /usr/local/bin/curl $ mv usr/local/bin/curl . $ rm curl.txz $ fetch -o carootnss.txz http://distcache.freebsd.org/freebsd:10:x86:64/latest/All/ca_root_nss-3.22.2.txz $ tar xvf carootnss.txz /usr/local/share/certs/ca-root-nss.crt $ mv /usr/local/share/certs/ca-root-nss.crt . $ rm carootnss.txz $ # rm -r usr # be sure you're not in / ;-) ``` ## 3. Configure your shell Your shell needs to know how to use the new curl binary. Create a file `_shell_profile` in same directory as above: `_shell_profile`: ``` export CURL_CA_BUNDLE=/ca-root-nss.crt export PATH=$PATH: ``` Load it in your current shell session: ``` $ . _shell_profile ``` ## 4. Install acme.sh Now download and install acme.sh using the [advanced configuration](https://github.com/Neilpang/acme.sh/wiki/How-to-install#4-advanced-installation). ``` ./acme.sh --install --home ``` You can now use it as usual. ## 5. Certificate renewal with cronjob Usually, acme.sh can't create the automatic cronjob for certificate renewal on those platforms. I use a script like this: `acme-renew.sh`: ``` . /_shell_profile acme.sh --cron --home ``` Don't forget to `chmod +x acme-renew.sh`. Now find out how to create the cronjob on your system. For nas4free, you can do it in the web interface under **System -> Advanced -> Cron**. I scheduled it for running on the 1st of every month.acme.sh-0.0~git20250417.7502af3/Install-in-China.md000066400000000000000000000007071500024665000207620ustar00rootroot00000000000000如果你的安装服务器位于中国大陆境内, 访问 github 可能会不成功. 所以安装可能会失败. 1. 推荐从这里下载安装: https://gitee.com/neilpang/acme.sh ### 安装步骤: 根据 [How-to-install#3-or-git-clone-and-install](https://github.com/acmesh-official/acme.sh/wiki/How-to-install#3-or-git-clone-and-install) ``` git clone https://gitee.com/neilpang/acme.sh.git cd acme.sh ./acme.sh --install -m my@example.com ```acme.sh-0.0~git20250417.7502af3/Install-preparations.md000066400000000000000000000005501500024665000220370ustar00rootroot00000000000000# 1. Ubuntu/Debian: ``` apt-get install openssl cron socat curl ``` # 2. CentOS ``` yum -q -y install openssl crontabs socat curl ``` For centos 5: ``` yum -q -y install openssl vixie-cron socat curl ``` # 3. alpine ``` apk --no-cache add -f openssl curl socat ``` # 4. kalilinux ``` apt-get -qqy install openssl cron socat curl ``` acme.sh-0.0~git20250417.7502af3/Issue-a-cert-from-existing-CSR.md000066400000000000000000000015521500024665000234060ustar00rootroot00000000000000From v2.4.4, acme.sh support to issue a cert from an existing csr. There are 2 commands related: ### 1. Display the content of the csr ``` acme.sh --showcsr --csr /path/to/mycsr.csr ``` It shows the subject and domain names in the csr. ### 2. Issue a cert from the csr ``` acme.sh --signcsr --csr /path/to/mycsr.csr -w /path/to/webroot/ ``` The first parameter is the csr file, all the other parameters are same as `--issue` command. For example, you can specify different webroot folders for each domain in the csr: ``` acme.sh --signcsr --csr /path/to/mycsr/csr -w /wwwroot/aa.com -w /wwwroot/www.aa.com -w /wwwroot/bb.com ``` Another example, using dns mode: ``` acme.sh --signcsr --csr /path/to/mycsr/csr --dns dns_cf ``` The parameters are same as `--issue` command. See : https://github.com/Neilpang/acme.sh/wiki/How-to-issue-a-cert acme.sh-0.0~git20250417.7502af3/OVH-Success.md000066400000000000000000000002021500024665000177600ustar00rootroot00000000000000# OVH authentication Success ! If you see this page, it means your authentication is ok. Go back to your shell, and try again. acme.sh-0.0~git20250417.7502af3/Options-and-Params.md000066400000000000000000000251151500024665000213440ustar00rootroot00000000000000``` Usage: acme.sh ... [parameters ...] Commands: -h, --help Show this help message. -v, --version Show version info. --install Install acme.sh to your system. --uninstall Uninstall acme.sh, and uninstall the cron job. --upgrade Upgrade acme.sh to the latest code from https://github.com/acmesh-official/acme.sh. --issue Issue a cert. --deploy Deploy the cert to your server. -i, --install-cert Install the issued cert to apache/nginx or any other server. -r, --renew Renew a cert. --renew-all Renew all the certs. --revoke Revoke a cert. --remove Remove the cert from list of certs known to acme.sh. --list List all the certs. --to-pkcs12 Export the certificate and key to a pfx file. --to-pkcs8 Convert to pkcs8 format. --sign-csr Issue a cert from an existing csr. --show-csr Show the content of a csr. -ccr, --create-csr Create CSR, professional use. --create-domain-key Create an domain private key, professional use. --update-account Update account info. --register-account Register account key. --deactivate-account Deactivate the account. --create-account-key Create an account private key, professional use. --install-cronjob Install the cron job to renew certs, you don't need to call this. The 'install' command can automatically install the cron job. --uninstall-cronjob Uninstall the cron job. The 'uninstall' command can do this automatically. --cron Run cron job to renew all the certs. --set-notify Set the cron notification hook, level or mode. --deactivate Deactivate the domain authz, professional use. --set-default-ca Used with '--server', Set the default CA to use. See: https://github.com/acmesh-official/acme.sh/wiki/Server Parameters: -d, --domain Specifies a domain, used to issue, renew or revoke etc. --challenge-alias The challenge domain alias for DNS alias mode. See: https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode --domain-alias The domain alias for DNS alias mode. See: https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode --preferred-chain If the CA offers multiple certificate chains, prefer the chain with an issuer matching this Subject Common Name. If no match, the default offered chain will be used. (default: empty) See: https://github.com/acmesh-official/acme.sh/wiki/Preferred-Chain -f, --force Force install, force cert renewal or override sudo restrictions. --staging, --test Use staging server, for testing. --debug [0|1|2|3] Output debug info. Defaults to 1 if argument is omitted. --output-insecure Output all the sensitive messages. By default all the credentials/sensitive messages are hidden from the output/debug/log for security. -w, --webroot Specifies the web root folder for web root mode. --standalone Use standalone mode. --alpn Use standalone alpn mode. --stateless Use stateless mode. See: https://github.com/acmesh-official/acme.sh/wiki/Stateless-Mode --apache Use apache mode. --dns [dns_hook] Use dns manual mode or dns api. Defaults to manual mode when argument is omitted. See: https://github.com/acmesh-official/acme.sh/wiki/dnsapi --dnssleep The time in seconds to wait for all the txt records to propagate in dns api mode. It's not necessary to use this by default, acme.sh polls dns status by DOH automatically. -k, --keylength Specifies the domain key length: 2048, 3072, 4096, 8192 or ec-256, ec-384, ec-521. -ak, --accountkeylength Specifies the account key length: 2048, 3072, 4096 --log [file] Specifies the log file. Defaults to "/root/.acme.sh/acme.sh.log" if argument is omitted. --log-level <1|2> Specifies the log level, default is 1. --syslog <0|3|6|7> Syslog level, 0: disable syslog, 3: error, 6: info, 7: debug. --eab-kid Key Identifier for External Account Binding. --eab-hmac-key HMAC key for External Account Binding. These parameters are to install the cert to nginx/apache or any other server after issue/renew a cert: --cert-file Path to copy the cert file to after issue/renew.. --key-file Path to copy the key file to after issue/renew. --ca-file Path to copy the intermediate cert file to after issue/renew. --fullchain-file Path to copy the fullchain cert file to after issue/renew. --reloadcmd Command to execute after issue/renew to reload the server. --server ACME Directory Resource URI. (default: https://acme.zerossl.com/v2/DV90) See: https://github.com/acmesh-official/acme.sh/wiki/Server --accountconf Specifies a customized account config file. --home Specifies the home dir for acme.sh. --cert-home Specifies the home dir to save all the certs, only valid for '--install' command. --config-home Specifies the home dir to save all the configurations. --useragent Specifies the user agent string. it will be saved for future use too. -m, --email Specifies the account email, only valid for the '--install' and '--update-account' command. --accountkey Specifies the account key path, only valid for the '--install' command. --days Specifies the days to renew the cert when using '--issue' command. The default value is 60 days. --httpport Specifies the standalone listening port. Only valid if the server is behind a reverse proxy or load balancer. --tlsport Specifies the standalone tls listening port. Only valid if the server is behind a reverse proxy or load balancer. --local-address Specifies the standalone/tls server listening address, in case you have multiple ip addresses. --listraw Only used for '--list' command, list the certs in raw format. -se, --stop-renew-on-error Only valid for '--renew-all' command. Stop if one cert has error in renewal. --insecure Do not check the server certificate, in some devices, the api server's certificate may not be trusted. --ca-bundle Specifies the path to the CA certificate bundle to verify api server's certificate. --ca-path Specifies directory containing CA certificates in PEM format, used by wget or curl. --no-cron Only valid for '--install' command, which means: do not install the default cron job. In this case, the certs will not be renewed automatically. --no-profile Only valid for '--install' command, which means: do not install aliases to user profile. --no-color Do not output color text. --force-color Force output of color text. Useful for non-interactive use with the aha tool for HTML E-Mails. --ecc Specifies to use the ECC cert. Valid for '--install-cert', '--renew', '--revoke', '--to-pkcs12' and '--create-csr' --csr Specifies the input csr. --pre-hook Command to be run before obtaining any certificates. --post-hook Command to be run after attempting to obtain/renew certificates. Runs regardless of whether obtain/renew succeeded or failed. --renew-hook Command to be run after each successfully renewed certificate. --deploy-hook The hook file to deploy cert --ocsp, --ocsp-must-staple Generate OCSP-Must-Staple extension. --always-force-new-domain-key Generate new domain key on renewal. Otherwise, the domain key is not changed by default. --auto-upgrade [0|1] Valid for '--upgrade' command, indicating whether to upgrade automatically in future. Defaults to 1 if argument is omitted. --listen-v4 Force standalone/tls server to listen at ipv4. --listen-v6 Force standalone/tls server to listen at ipv6. --openssl-bin Specifies a custom openssl bin location. --use-wget Force to use wget, if you have both curl and wget installed. --yes-I-know-dns-manual-mode-enough-go-ahead-please Force use of dns manual mode. See: https://github.com/acmesh-official/acme.sh/wiki/dns-manual-mode -b, --branch Only valid for '--upgrade' command, specifies the branch name to upgrade to. --notify-level <0|1|2|3> Set the notification level: Default value is 2. 0: disabled, no notification will be sent. 1: send notifications only when there is an error. 2: send notifications when a cert is successfully renewed, or there is an error. 3: send notifications when a cert is skipped, renewed, or error. --notify-mode <0|1> Set notification mode. Default value is 0. 0: Bulk mode. Send all the domain's notifications in one message(mail). 1: Cert mode. Send a message for every single cert. --notify-hook Set the notify hook --revoke-reason <0-10> The reason for revocation, can be used in conjunction with the '--revoke' command. See: https://github.com/acmesh-official/acme.sh/wiki/revokecert --password Add a password to exported pfx file. Use with --to-pkcs12. ```acme.sh-0.0~git20250417.7502af3/Preferred-Chain.md000066400000000000000000000033311500024665000206620ustar00rootroot00000000000000Using `--preferred-chain` to select the alternate chain. If the ACME CA provides multiple cert chains, you can use `--preferred-chain` to select one. Otherwise, it will get the default chain. 1. For letsencrypt.org Staging Server: https://letsencrypt.org/docs/staging-environment/ There are 2 chains provided: | Name | Default | |-------------------------------|----------| | (STAGING) Pretend Pear X1 | No | | (STAGING) Bogus Broccoli X2 | Yes | You select the chain like: ``` acme.sh --issue -d example.com ..... --test --preferred-chain "(STAGING) Pretend Pear X1" ``` You can also use part of the name: ``` acme.sh --issue -d example.com ..... --test --preferred-chain "X1" ``` It's also case-insensitive: ``` acme.sh --issue -d example.com ..... --test --preferred-chain "x1" ``` 2. For Letsencrypt.org Production server: There are 2 chains provided: | Name | Default | |-------------------|-----------| | DST Root CA X3 | Yes | | ISRG Root X1 | No | You select the chain like: ``` acme.sh --issue -d example.com ..... --server letsencrypt --preferred-chain "ISRG Root X1" ``` You can also use part of the name: ``` acme.sh --issue -d example.com ..... --server letsencrypt --preferred-chain "ISRG" ``` It's also case-insensitive: ``` acme.sh --issue -d example.com ..... --server letsencrypt --preferred-chain "isrg" ``` 3. You can also set the default preferred chain for a specified CA(from v3.0.1). ``` acme.sh --set-default-chain --preferred-chain "ISRG" --server letsencrypt ``` When you request a cert from letsencrypt in future, it will use the default preferred chain. acme.sh-0.0~git20250417.7502af3/Run-acme.sh-in-docker.md000066400000000000000000000042741500024665000216640ustar00rootroot00000000000000# acme.sh 💕 docker As one of the big docker fans, I understand that we hate installing anything on a docker host, even if it's just copying a shell script. ### Automated nginx reverse proxy docker image with acme.sh for letsencrypt ssl cert: https://github.com/Neilpang/letsproxy ### Deploy to a docker container and reload it: https://github.com/Neilpang/acme.sh/wiki/deploy-to-docker-containers So, Here "acme.sh in docker" comes. 1. Based on **alpine**, only 5MB size. 1. Either run as executable or run as daemon 1. Support all the command line parameters. # 1. Say "Hello World" ```sh docker run --rm neilpang/acme.sh ``` # 2. Used as an executable: ```sh docker run --rm -it \ -v "$(pwd)/out":/acme.sh \ --net=host \ neilpang/acme.sh --issue -d example.com --standalone ``` You can use **any commands** that **acme.sh** supports here, other examples: ```sh #revoke a cert docker run --rm -it \ -v "$(pwd)/out":/acme.sh \ --net=host \ neilpang/acme.sh --revoke -d example.com ``` ```sh #use dns mode docker run --rm -it \ -v "$(pwd)/out":/acme.sh \ neilpang/acme.sh --issue --dns -d example.com ``` ```sh #run cron job docker run --rm -it \ -v "$(pwd)/out":/acme.sh \ --net=host \ neilpang/acme.sh --cron ``` Anyway, you can just invoke **neilpang/acme.sh** image as if it were a real shell script. # 3. Run acme.sh as a docker daemon. ### 1. Running acme.sh as a docker daemon, so that it can handle the renewal cronjob automatically. ```sh docker run --rm -itd \ -v "$(pwd)/out":/acme.sh \ --net=host \ --name=acme.sh \ neilpang/acme.sh daemon ``` Or run acme.sh by using `Docker Compose`. Edit `docker-compose.yml`: ```yaml services: acme-sh: image: neilpang/acme.sh container_name: acme.sh volumes: - ./out:/acme.sh network_mode: host command: daemon stdin_open: true tty: true restart: no ``` Then run acme.sh: ```sh docker compose up -d ``` ### 2. Then you can just use `docker exec` to execute any acme.sh commands. ```sh docker exec acme.sh --help ``` ```sh docker exec acme.sh --issue -d example.com --standalone ``` Yes, again, You can use **any commands** that **acme.sh** supports here. acme.sh-0.0~git20250417.7502af3/SSL.com-CA.md000066400000000000000000000020141500024665000174200ustar00rootroot00000000000000SSL.com is providing free 104 days certs. The cert can only contain one domain and its `www` sub domain. No wildcard certs. ``` acme.sh --server ssl.com --issue -d example.com -d www.example.com ........ ``` Please register a free account at www.ssl.com, and then get your EAB Credentials: https://www.ssl.com/guide/ssl-tls-certificate-issuance-and-revocation-with-acme/#ftoc-heading-2 Next: 1. Register an account: ```sh acme.sh --register-account --server ssl.com \ -m my@example.com \ --eab-kid xxxxxx --eab-hmac-key xxxxxxxx ``` And also register an ECDSA account: ```sh acme.sh --register-account --server ssl.com \ -m my@example.com \ --eab-kid xxxxxx --eab-hmac-key xxxxxxxx --ecc ``` 2. Then you can issue certs with `--server` parameter: ```sh acme.sh --issue -d example.com --dns dns_cf --server ssl.com ``` Or, issue an ECDSA cert: ``` acme.sh --issue -d example.com --dns dns_cf --server ssl.com -k ec-256 ``` acme.sh-0.0~git20250417.7502af3/Server.md000066400000000000000000000041621500024665000171750ustar00rootroot00000000000000For the `--server` parameter, you can specify an ACME server directory URL, and you can also give a short friendly name for known CAs. The supported short names are: | Short Name | ACME server URL | Usage Wiki | |--------------------| -------------------|------| | letsencrypt | https://acme-v02.api.letsencrypt.org/directory | N/A | | letsencrypt_test | https://acme-staging-v02.api.letsencrypt.org/directory | N/A | | buypass | https://api.buypass.com/acme/directory | [BuyPass.com CA](https://github.com/acmesh-official/acme.sh/wiki/BuyPass.com-CA) | | buypass_test | https://api.test4.buypass.no/acme/directory | [BuyPass.com CA](https://github.com/acmesh-official/acme.sh/wiki/BuyPass.com-CA) | | zerossl | https://acme.zerossl.com/v2/DV90 | [ZeroSSL.com CA](https://github.com/acmesh-official/acme.sh/wiki/ZeroSSL.com-CA) | | sslcom | https://acme.ssl.com/sslcom-dv-rsa, https://acme.ssl.com/sslcom-dv-ecc | [SSL.com CA](https://github.com/acmesh-official/acme.sh/wiki/SSL.com-CA) | | google | https://dv.acme-v02.api.pki.goog/directory | [Google Public CA](https://github.com/acmesh-official/acme.sh/wiki/Google-Trust-Services-CA) | | googletest | https://dv.acme-v02.test-api.pki.goog/directory | [Google Public CA](https://github.com/acmesh-official/acme.sh/wiki/Google-Trust-Services-CA) | The short name will be treated as the same as the URL: The following usages have the same meaning: ``` acme.sh --issue .... --server zerossl -or- acme.sh --issue .... --server https://acme.zerossl.com/v2/DV90 ``` For now, the default CA is `zerossl`. If you want to use another CA, you need to specify `--server` for each command. For example, if your want to use `letsencrypt` CA : ``` acme.sh --register-account --server letsencrypt -m myemail@example.com --or-- acme.sh --issue --server letsencrypt -d example.com --dns dns_cf ``` There is a way to change the default CA: ``` acme.sh --set-default-ca --server letsencrypt ``` From now on, you will issue cert from `letsencrypt` if you don't specify any `--server` parameter. ``` acme.sh --issue -d example.com --dns dns_cf ``` acme.sh-0.0~git20250417.7502af3/Simple-guide-to-add-TLS-cert-to-cpanel.md000066400000000000000000000115661500024665000247020ustar00rootroot00000000000000# How to use acme.sh with cPanel for automatically renewing Let's Encrypt SSL This guide will demonstrate how to use acme.sh with a cPanel account to setup automatically renewing Let's Encrypt certificates. **Prerequisites**: SSH access to your cPanel account is required. Contact your host to find out whether this is available. Sometimes they will enable it on request. In the example commands below, make the following substitutions: | Variable | Substitute With | Example Value | |----------|-----------------|---------------| | `_EXAMPLE.COM_` | The domain name you want an SSL certificate for. | `example.com` | | `_CPANEL_USERNAME_` | The username you use to login to cPanel | `user123` | | `_SSH_PORT_` | The port number you use to connect to SSH (ask your cPanel provider) | `22` | | `_SSH_ADDRESS_` | The server address you use to connect to SSH (ask your cPanel provider) | `cpanel-123.example-host.com` | *** ## 1. Setting up acme.sh in cPanel. Login to your cPanel account via SSH: ssh -l _CPANEL_USERNAME_ -p _SSH_PORT_ _SSH_ADDRESS_ Install acme.sh with the following command: curl https://get.acme.sh | sh Log-off and login to SSH again, or run the following command: source ~/.bashrc Tell acme.sh to set Let's Encrypt as the default CA server (required since Aug 2021): acme.sh --set-default-ca --server letsencrypt Register a Let's Encrypt account with your email, so you can be notified of any renewal issues: acme.sh --register-account --accountemail email@example.com And confirm that acme.sh has setup a cron job for automatic renewals: crontab -l | grep acme.sh # The above command should output something like the below: 10 0 * * * "/home/_CPANEL_USERNAME_/.acme.sh"/acme.sh --cron --home "/home/_CPANEL_USERNAME_/.acme.sh" > /dev/null *** ## 2. Issuing a test certificate for your domain. We will use the [webroot](https://github.com/Neilpang/acme.sh/wiki/How-to-issue-a-cert#1-webroot-mode) method, which requires you to enter the document root of your domain. The webroot for your main domain is `~/public_html`, but addon domains and subdomains will be located in other directories.
(Click to see how you can locate the webroot for a domain using the uapi command) uapi DomainInfo single_domain_data domain=_EXAMPLE.COM_ | grep documentroot
Try issue a test certificate now: acme.sh --issue --webroot ~/public_html -d _EXAMPLE.COM_ --staging If this domain has alias/parked domains, include those with additional `-d` parameters, such as: acme.sh --issue --webroot ~/public_html -d example.com -d www.example.com --staging **Note that the above test certificate would Issue ECC certificates which may get stored in your directory `/home/CPANEL_USERNAME/.acme.sh/domain.com_ecc`, and may cause your SSL issued but not working** Instead, use this method to test certificates for (RSA2048),(RSA3072) or (RSA4096) acme.sh --issue --webroot ~/public_html -d example.com -d www.example.com --keylength 2048 --staging Ensure that this step is successful. If you encountered an error, ensure that the webroot is correct, or try to run acme.sh with `--debug 2` for further information. ## 3. Issuing a real certificate for your domain. Use the same parameters as for your test certificate, except replace `--staging` with `--force`: acme.sh --issue --webroot ~/public_html -d _EXAMPLE.COM_ --force **Note that the above test certificate would Issue ECC certificates which may get stored in your directory `/home/CPANEL_USERNAME/.acme.sh/domain.com_ecc`, and may cause your SSL issued but not working** Instead, use this method to test certificates for (RSA2048),(RSA3072) or (RSA4096) acme.sh --issue --webroot ~/public_html -d example.com -d www.example.com --keylength 2048 --force This re-issues the certificate as a real, trusted SSL certificate, rather than a test one from the [staging environment](https://letsencrypt.org/docs/staging-environment/). *** ## 4. Installing your certificate to your cPanel account. After issuing the real certificate, we need to tell acme.sh how to install it to our domain, so it can automatically perform that task at every renewal. acme.sh --deploy --deploy-hook cpanel_uapi --domain _EXAMPLE.COM_ This should result in a success message: [Tue Aug 6 03:56:25 EDT 2019] Certificate successfully deployed [Tue Aug 6 03:56:25 EDT 2019] Success You should now be able to visit your domain in your browser and see that it is protected by a Let's Encrypt certificate. **Please note, this will only deploy to a single virtualhost in your cPanel account. For other addon and subdomains, you should create separate certificates.**. *** ## 5. Redirecting HTTP to HTTPS for your domain (Optional). To automatically redirect insecure HTTP traffic to HTTPS, please enable *Force HTTPS Redirection* in cPanel: https://blog.cpanel.com/force-https-redirection/ *** acme.sh-0.0~git20250417.7502af3/Stateless-Mode.md000066400000000000000000000050371500024665000205620ustar00rootroot00000000000000## Stateless Mode Configure your webserver to respond statelessly to challenges for a given account key. This requires nothing more than a one-time web server configuration change and no "moving parts". 1. First get your account key thumbprint: ``` root@ed:~# acme.sh --register-account [Mon Feb 6 21:40:18 CST 2017] Registering account [Mon Feb 6 21:40:19 CST 2017] Already registered [Mon Feb 6 21:40:21 CST 2017] Update success. [Mon Feb 6 21:40:21 CST 2017] ACCOUNT_THUMBPRINT='6fXAG9VyG0IahirPEU2ZerUtItW2DHzDzD9wZaEKpqd' ``` Remember the thumbprint in the last line: ` 6fXAG9VyG0IahirPEU2ZerUtItW2DHzDzD9wZaEKpqd ` 1. Configure the web server to return the account key thumbprint: ### NGINX Add something similar to your `nginx.conf`: ```nginx http { ... server { ... location ~ ^/\.well-known/acme-challenge/([-_a-zA-Z0-9]+)$ { default_type text/plain; return 200 "$1.6fXAG9VyG0IahirPEU2ZerUtItW2DHzDzD9wZaEKpqd"; } ... } } ``` ### CADDY Add something similar to your `Caddyfile`: ```Caddyfile example.com { @achallenge { path_regexp ch ^/\.well-known/acme-challenge/([-_a-zA-Z0-9]+)$ } respond @achallenge "{re.ch.1}.6fXAG9VyG0IahirPEU2ZerUtItW2DHzDzD9wZaEKpqd" ``` ### APACHE _Tested on Apache 2.4.62_ Add something similar to your `httpd.conf`: ```apache ... ... [-_a-zA-Z0-9]+)"> RewriteEngine On RewriteRule "^([-_a-zA-Z0-9]+)$" "$1" [E=challenge:$1] ErrorDocument 200 "%{ENV:MATCH_CHALLENGE}.6fXAG9VyG0IahirPEU2ZerUtItW2DHzDzD9wZaEKpqd" RewriteRule ^ - [L,R=200] ... ... ``` ### HAPROXY Add the http-request return rule to your configuration: ```haproxy global setenv ACCOUNT_THUMBPRINT '6fXAG9VyG0IahirPEU2ZerUtItW2DHzDzD9wZaEKpqd' log stderr local0 stats socket /var/run/haproxy.sock level admin mode 0666 frontend web log global option httplog mode http bind :80 bind :443 ssl crt /etc/haproxy/certs/ http-request return status 200 content-type text/plain lf-string "%[path,field(-1,/)].${ACCOUNT_THUMBPRINT}\n" if { path_reg '^/.well-known/acme-challenge/[-_a-zA-Z0-9]+$' } ``` 3. Ok, you can issue cert now. ``` acme.sh --issue -d example.com --stateless ``` acme.sh-0.0~git20250417.7502af3/Synology-NAS-Guide.md000066400000000000000000000212431500024665000212230ustar00rootroot00000000000000# HTTPS certificates for your Synology NAS using acme.sh Since Synology introduced [Let's Encrypt](https://letsencrypt.org/), many of us benefit from free SSL. On the other hand, many of us don't want to expose port 80/443 to the Internet, including opening ports on the router. The alternative is to use the DNS-01 protocol. Sadly the Synology implementation of Let's Encrypt currently (1-Jan-2017) only supports the HTTP-01 method which requires exposing port 80 to the Internet. Also, if the domain of your NAS has an IPv6 AAAA record set, the Synology implementation of Let's Encrypt will fail. But we can access the NAS via SSH and configure it to renew certs instead of using the web dashboard. The following guide will use the DNS-01 protocol using the [Cloudflare API](https://api.cloudflare.com/), where I host my domain. However, [since acme.sh supports many DNS services](https://github.com/acmesh-official/acme.sh/tree/master/dnsapi), you can also choose the one you like. With the [Synology DSM deployhook](https://github.com/acmesh-official/acme.sh/wiki/deployhooks#20-deploy-the-certificate-to-synology-dsm) included in 2.8.6, it is no longer required to run acme.sh on your Synology device to rotate the certificate. acme.sh just needs to be run on something that has access to the DSM's administrative interface. Additionally, the previous deployment methods can be drastically simplified with the following instructions. ## Installation of acme.sh ```sh sudo su cd ~ wget https://github.com/acmesh-official/acme.sh/archive/master.tar.gz tar xvf master.tar.gz cd acme.sh-master/ ./acme.sh --install --nocron --home /usr/local/share/acme.sh --accountemail "email@gmail.com" source ~/.profile ``` ## Configuring DNS For CloudFlare, we will set two environment variables that acme.sh (specifically, the `dns_cf` script from the `dnsapi` subdirectory) will read to set the DNS record. You can get your CloudFlare [API key here](https://dash.cloudflare.com/profile). ```sh export CF_Key="MY_SECRET_KEY_SUCH_SECRET" export CF_Email="myemail@example.com" ``` If you generated an API Token, instead of using your global account key, set CF_Token instead. ```sh export CF_Token="MY_SECRET_TOKEN_SUCH_SECRET" export CF_Email="myemail@example.com" ``` In case you use another DNS service, check the `dnsapi` directory and [DNS API guide](https://github.com/acmesh-official/acme.sh/wiki/dnsapi). Instructions for many DNS providers are already included. You can also find instructions on how to add another DNS service there, although that requires some software development skills. ## Creating the certificate Now it's time to create the certificate for your domain: Note: Since `v3`, `acme.sh` uses Zerossl as the default Certificate Authority (CA). Account registration (one-time) is required before one can issue new certs. See: https://github.com/acmesh-official/acme.sh/wiki/ZeroSSL.com-CA ```sh # These commands assume you are still working in the same terminal and have ran necessary commands described above. cd /usr/local/share/acme.sh export CERT_DOMAIN="your-domain.tld" export CERT_DNS="dns_cf" ./acme.sh --issue --server letsencrypt --home . -d "$CERT_DOMAIN" --dns "$CERT_DNS" --keylength 2048 ``` ## Deploy the default certificate We will use the [Synology DSM deployhook](https://github.com/acmesh-official/acme.sh/wiki/deployhooks#20-deploy-the-certificate-to-synology-dsm) to deploy our certificate. This will override the default certificate (if you haven't set any description for it), you can learn how to create new certificates to be used for other services later in this section. **The commands in the code block in this section assume you are still working in the same terminal and executed necessary commands described above.** ### Deploy with temp or existing admin user #### (Recommend) Deploy with auto created temp admin user If you installed `acme.sh` in DSM, we recommend you to try automatic temp user auth method to deploy (DSM should already have required built-in tools, we will let you know if not): ```sh export SYNO_USE_TEMP_ADMIN=1 ./acme.sh --deploy --home . -d "$CERT_DOMAIN" --deploy-hook synology_dsm ``` In this way, you won't need to provide any admin credentials, the deploy script itself will utilize Synology built-in utils to complete authentication, so it is designed to only support local deployment, and can't be used to deploy in docker or deploy remotely. Script will load previous saved conf for subsequent deployments, so if you want to switch back to deploy with existing admin user, you need to execute `export CLEAR_SYNO_USE_TEMP_ADMIN=1` first. After deploy script exits, the temp admin user should either not have been created or has already been deleted, however it may still remain if script exits unexpectedly (e.g., aborted by pressing "Ctrl+C"), in this case, you can safely delete it via "Control Panel". #### Deploy with existing admin user If you prefer to deploy with existing admin user or if the above way is not available (e.g., installed in docker, want to deploy remotely, etc.), you need to provide your own credentials: ```sh # Single quotes prevents some escaping issues if your password or username contains certain special characters export SYNO_USERNAME='Admin_Username' export SYNO_PASSWORD='Admin_Password!123' ./acme.sh --deploy --home . -d "$CERT_DOMAIN" --deploy-hook synology_dsm ``` Note that if the user specified by `SYNO_Username` has enabled two-factor authentication (2FA), the script will require you to manually input the TOTP code just like you were logging in on the Web UI (if you didn't provide the code via `export SYNO_OTP_CODE=XXXXXX`), it will also require you to input the device name for verification (also can be provided via like `export SYNO_DEVICE_NAME=CertRenewal`), then obtain to store necessary info which can be used to omit the TOTP, so you won't need to do manually input again in the future. > BTW, as you may know if you used to use this script to deploy, the necessary info here now is so-called parameter "Device ID", if you are a pro user and want to obtain it manually, you still can, method in short: log into your DSM via its website, making sure you've ticked `Remember this device` when asked for your OTP, get the `did` cookie's value and set the environment variable `SYNO_DEVICE_ID`: ```sh export SYNO_DEVICE_ID='YOUR VALUE' ./acme.sh --deploy --home . -d "$CERT_DOMAIN" --deploy-hook synology_dsm ``` ### Use HTTPS to deploy When we want to use HTTPS to deploy the new certificate and connect to "localhost", we need to add the --insecure option to the deploy command to prevent curl errors. Refer to [https://github.com/acmesh-official/acme.sh/wiki/Options-and-Params]. If you enabled HTTP/2 you still receive a curl 16 error probably due to missing http2 dependencies on the NAS but the script succeeds. ```sh # export SYNO_HOSTNAME="localhost" # Specify if not using on localhost export SYNO_SCHEME="https" export SYNO_PORT="5001" ./acme.sh --deploy --insecure --home . -d "$CERT_DOMAIN" --deploy-hook synology_dsm ``` Additionally, if you are using temp admin method to deploy, to prevent confusion, the value of `SYNO_HOSTNAME` must target to current local machine (can be `localhost` or `127.0.0.1`), however if your custom SYNO_HOSTNAME does indeed target to current local machine, you should execute `export SYNO_LOCAL_HOSTNAME=1` before deploying. ### Deploying additional certificates By specifying a different `SYNO_CERTIFICATE` (and set `SYNO_CREATE=1` for creating), we can deploy multiple certificates to the DSM. ```sh # SYNO_Certificate is the description shown under Security -> Certificates in the DSM Control Panel export SYNO_CERTIFICATE="A different certificate description" export SYNO_CREATE=1 # Says to create the certificate if it doesn't exist ./acme.sh --deploy --home . -d "subdomain.$CERT_DOMAIN" --deploy-hook synology_dsm ``` ## Configuring Certificate Renewal To auto renew the certificates in the future, you need to configure a task in the task scheduler. It is not advised to set this up as a custom cronjob (as was previously described in this wiki page) as the DSM security advisor will tell you that you have a critical warning regarding unknown cronjob(s). In DSM control panel, open the 'Task Scheduler' and create a new scheduled task for a user-defined script. * General Setting: Task - Update default Cert. User - root * Schedule: Setup a weekly renewal. For example, 11:00 am every saturday. * Task setting: User-defined-script: ```sh # renew certificates /usr/local/share/acme.sh/acme.sh --cron --home /usr/local/share/acme.sh ``` ## Fix a broken environment after Synology DSM upgrade ```sh ./acme.sh --force --upgrade --nocron --home . ``` or manually add below line into /root/.profile ```sh . "/usr/local/share/acme.sh/acme.sh.env" ```acme.sh-0.0~git20250417.7502af3/Synology-RT1900ac-and-RT2600ac-install-guide.md000066400000000000000000000064031500024665000253510ustar00rootroot00000000000000I got tired of manually maintaining Let's Encrypt on my laptop to update my Router. so I now pushed that to the router itself. here's the HowTo (xpost https://forum.synology.com/enu/viewtopic.php?f=265&t=123003 ). I've used https://github.com/Neilpang/acme.sh , a 3rd party client for Let's Encrypt, based on shell scripting. no extra dependencies. I've also used it with DNS01 protocol, which means, I don't have any ports open on the router to do the validation, instead it use Cloudflare API, where I host my domain. You can use any name service provider which has an API to automatically add/update the txt record for certificate renewal. See the wiki page on [DNS API Mode](https://github.com/Neilpang/acme.sh/wiki/How-to-issue-a-cert#5-dns-api-mode). Since the Router shell is very limited, there are several constraints. the most important of all, there is no crontab. Trying the following default install will fail because of crontab. ``` $ wget -O - https://get.acme.sh | sh ``` Therefore we have to do it manually: ``` $ wget https://github.com/Neilpang/acme.sh/archive/master.tar.gz $ tar xvf master.tar.gz $ cd acme.sh-master/ $ ./acme.sh --install --nocron --home /volume1/@appstore/acme.sh log out and login to ssh again ``` Installation is done :) Next, configure: ``` $ cd /volume1/@appstore/acme.sh ``` Configure your credentials for DNS API mode. When using Cloudflare, you'll need your Cloudflare email and API key which you can get [here](https://www.cloudflare.com/a/account/my-account). Type this to the shell, replace with the values above. Again, see the wiki page on [DNS API Mode](https://github.com/Neilpang/acme.sh/wiki/How-to-issue-a-cert#5-dns-api-mode) to learn about other DNS API modes. ``` export CF_Key="sdfsdfsdfljlbjkljlkjsdfoiwje" export CF_Email="xxxx@sss.com" ``` Now to create your cert: ``` $ ./acme.sh --issue \ --post-hook "/usr/syno/sbin/synoservicecfg --restart httpd-sys" \ --dns dns_cf \ --certpath /usr/syno/etc/ssl/ssl.crt/server.crt \ --keypath /usr/syno/etc/ssl/ssl.key/server.key \ --ca-file /usr/syno/etc/ssl/ssl.crt/ca.crt \ --config-home /volume1/@appstore/acme.sh \ --dnssleep 15 -d YOURDOMAIN.TLD ``` Simple right? Since there is no crontab, we need to manually add it to cron. The Let's Encrypt cert expires in 90 days, so the recommended renewal date is 1 month before expiration, i.e. every 2 months. Use a [crontab tester](https://crontab.guru/#3_2_1_1,3,5,7,9,11_*) if you need help with this part. The following updates the certificates at 02:03 on the 1st day in January, March, May, July, September, and November. ``` $ vi /etc/crontab 3 2 1 1,3,5,7,9,11 * root /volume1/@appstore/acme.sh/acme.sh --cron --home /volume1/@appstore/acme.sh :wq ``` HTH ## CA Cert Configuration My router, running SRM version 1.2.5-8227 Update 2, requires the following additional web server configuration lines to make the above work. This may be required because the router still thinks it's using a self-signed cert, so those directives are commented out by default. I added the lines to `/etc/httpd/conf/extra/httpd-ssl.conf-cipher`. ``` SSLCACertificatePath "/usr/syno/etc/ssl/ssl.crt" SSLCACertificateFile "/usr/syno/etc/ssl/ssl.crt/ca.crt" ``` Reload the web server using the post-hook command above after adding the lines.acme.sh-0.0~git20250417.7502af3/TLS-ALPN-without-downtime.md000066400000000000000000000102451500024665000224450ustar00rootroot00000000000000# Using TLS-ALPN without downtime acme.sh added support for TLS-ALPN on 2018-12-28. This feature allows domain validation to be performed over port 443, useful when port 80 is not accessible. However, the feature requires any existing webservers on that port to be shut down so that acme.sh can listen on port 443. This article outlines some ways it is possible to configure webservers to work transparently with acme.sh's TLS-ALPN support without having to stop and start your webserver. ## Compatibility | Webserver | Status | Caveats | |-----------|--------|---------| | Apache httpd | Not possible | Consider using [mod_md](https://github.com/icing/mod_md), which is an Apache module that replaces acme.sh. It can perform TLS-ALPN validation since version 1.99. | | nginx | Supported | Requires [ngx_stream_ssl_preread_module](http://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html) to be compiled. e.g. on Ubuntu 18.04, included in the `nginx-full` package. | | HAProxy | Supported | Requires HAProxy >= 1.9.1 ## Instructions ### nginx With nginx, what we do is create a TLS-ALPN load balancer within nginx on port 443, and re-assign all existing HTTPS virtual hosts within nginx to another port. When a TLS-ALPN connection comes in, it is routed to acme.sh, otherwise, the connection is routed to the HTTPS virtual hosts. 1\. Verify that nginx is compiled with the required module: $ nginx -V 2>&1 | grep -o ssl_preread ssl_preread 2\. Re-assign ALL port 443 virtual hosts to another port If you have existing HTTPS virtual hosts listening on port 443, you will need to re-assign each HTTPS server to an alternate port (such as 8443), so that we can put the ALPN load balancer on port 443. For example ```nginx server { server_name example.org; listen 443; # ... } ``` would become ```nginx server { server_name example.org; listen 8443; # ... } ``` 3\. Add the ALPN load balancer In `/etc/nginx.conf`, at the end of the file, add (substituting `8443` for the port chosen in step 2): ```nginx stream { map $ssl_preread_alpn_protocols $tls_port { ~\bacme-tls/1\b 10443; default 8443; } server { listen 443; listen [::]:443; proxy_pass 127.0.0.1:$tls_port; ssl_preread on; } } ``` 4\. Make sure the configuration works and reload. $ sudo nginx -t $ sudo systemctl reload nginx 5\. Try to issue a certificate (substituting `example.org` for the domain you want on your certificate). $ sudo acme.sh --issue --alpn --tlsport 10443 -d example.org ### HAProxy With HAProxy, what we have to do is run an ALPN load balancer frontend in TCP mode on port 443, and re-assign all HTTPS frontends to an alternate port. When a TLS-ALPN connection for ACME comes in, it will be routed to acme.sh, otherwise, the connection is forwarded to the normal HTTPS frontend. 1\. Verify that HAProxy is at least version 1.9.1: $ haproxy -v HA-Proxy version 1.9.2 2019/01/16 - https://haproxy.org/ 2\. In the HAProxy configuration, as well as re-assigning your existing HTTPS (443) frontend to port 8443, you will need to add: 1. `fe_alpn` - a TCP frontend on 443 to load balance ALPN 2. `bk_acmesh` - A backend to send requests to acme.sh 3. `bk_https` - A backend to send requests to your regular HTTPS frontend In this example the PROXY protocol is used between `bk_https` and `fe_https` so the original clients source IP is known. ```haproxy # New frontend fe_alpn mode tcp bind :443 tcp-request inspect-delay 5s tcp-request content accept if { req_ssl_hello_type 1 } use_backend bk_acmesh if { req.ssl_alpn acme-tls/1 } default_backend bk_https # New backend bk_acmesh server acmesh 127.0.0.1:10443 # New backend bk_https server https 127.0.0.1:8443 send-proxy-v2 # Existing, changed from :443 -> 127.0.0.1:8443 frontend fe_https mode http bind 127.0.0.1:8443 ssl crt /etc/ssl/haproxy.pem accept-proxy # ... ``` 3\. Make sure the configuration works and reload: $ sudo haproxy -c -f /etc/haproxy.cfg $ sudo systemctl reload haproxy 4\. Try to issue a certificate (substituting `example.org` for the domain you want on your certificate). $ sudo acme.sh --issue --alpn --tlsport 10443 -d example.orgacme.sh-0.0~git20250417.7502af3/Usage-on-Tomato-routers.md000066400000000000000000000206361500024665000223530ustar00rootroot00000000000000This article describes using a router with Linux-based [Tomato firmware](https://en.wikipedia.org/wiki/Tomato_(firmware)) to run name-based HTTPS [reverse proxies](https://en.wikipedia.org/wiki/Reverse_proxy) with [Let's Encrypt](https://letsencrypt.org/) certificates, using [acme.sh](https://github.com/acmesh-official/acme.sh), providing encrypted access to home or small business LAN services from outside (untrusted) networks, such as your mobile devices. Traffic to HTTPS port(s) (the usual 443 or whatever you use) in your public IP address will be forwarded to plain HTTP services on your LAN hosts with your Tomato router functioning as a reverse proxy. This way you can have multiple (sub)domains in a single public port pointed to several LAN servers with Tomato handling all the HTTPS work, which is not possible with simple port forwarding. A configuration example is provided. Much of the setup is done through SSH, but you'll also need Tomato's web interface, marked in this guide as **Menu→Submenu**. ### Prerequisites - A router with USB ports running [FreshTomato](https://freshtomato.org/) or another recent Tomato fork with a fully featured OpenSSL and web server. A fast CPU and large NVRAM are recommended. There's an [unconfirmed report](https://github.com/acmesh-official/acme.sh/issues/1581#issuecomment-651678412) of MIPS-based routers having problems, possibly because of missing ext4 support, but ext3 or ext2 can be used instead. - Unless you happen to have a static public IP, you need a dynamic DNS (**Basic→DDNS**) service configured in Tomato. Some [DNS services](https://community.letsencrypt.org/t/dns-providers-who-easily-integrate-with-lets-encrypt-dns-validation/86438) also provide API control, enabling [DNS mode](https://github.com/acmesh-official/acme.sh/wiki/dnsapi) for acme.sh. You can point additional regular CNAME records to the DDNS hostname, so not all your hostnames need to be dynamic. In this guide _tomato.example.com_ and _www.tomato.example.com_ are used as examples. - At least one plain HTTP web service or site running on either a LAN host or Tomato itself. It's a good idea to assign static IP addresses for servers (**Basic→Static DHCP/ARP/IPT** or **Basic→DHCP Reservation**). If you're going to [issue certificates](https://github.com/acmesh-official/acme.sh/wiki/How-to-issue-a-cert) using webroot mode, Tomato's web server must be running in port 80, so make sure your service provider doesn't block that port and that the web admin service (**Administration→Admin Access**) is not using the same port. **Standalone modes won't work**, as there's no `socat` in Tomato (without [entware](https://github.com/Entware/Entware/wiki)). ### Installing Format a USB HDD or flash drive as ext4 (or ext2 if you don't need journaling) and name the partition as you wish. For this guide the partition was named "flash", so Tomato auto-mounts it to `/tmp/mnt/flash`. **Don't forget to change every path mentioned in this guide to match the name you choose.** You could use Tomato's [JFFS partition](https://wiki.freshtomato.org/doku.php/admin-jffs2) instead of an external drive, but firmware upgrades may need JFFS disabled, so it's rather inconvenient. Besides, frequent writing may wear it out. SSH to your Tomato and paste these commands to download and extract acme.sh: ```sh cd /tmp/mnt/flash wget https://github.com/acmesh-official/acme.sh/archive/master.zip unzip master.zip rm master.zip cd acme.sh-master chmod +x acme.sh ``` You're now ready to install. Change the email address before running this install command: ```sh ./acme.sh --install --nocron --home /tmp/mnt/flash/acme.sh \ --accountemail "your.email@example.com" --useragent "Tomato router" ``` Finally remove the installer directory: `cd .. && rm -Rf acme.sh-master` The installer wrote a line to the `.profile` file in the root user's home directory. Tomato keeps this directory on a RAM disk that won't survive reboots, so you need to make this permanent by adding this line to **Administration→Scripts→Init**: ``` echo '. "/tmp/mnt/flash/acme.sh/acme.sh.env"' >> /tmp/home/root/.profile ``` Save the settings. Close the current SSH session and start a new one to activate the change. Now go to **Administration→Scheduler**. Scheduled commands ignore the `.profile` file, so you need to provide the full path to acme.sh and set the directory options. Put this line in one of the custom command fields and set it to run daily, preferrably at a time when there's least traffic: ```sh /tmp/mnt/flash/acme.sh/acme.sh --cron --home /tmp/mnt/flash/acme.sh --config-home /tmp/mnt/flash/acme.sh/conf ``` Save the scheduler settings. ### Configuring Tomato's web server If you'll only use DNS mode, you don't need to set the port and path; they're for acme.sh's webroot mode. Go to **Web Server→Basic Settings** and set it up like this: - Check **Enable Server on Start** and **Allow Remote Access** - **Run As**: Nobody (running as root is generally a bad idea) - **Web Server Port**: 80 - **Server Root Path**: `/tmp/mnt/flash/www` Save the settings. If the web server isn't running, click "Start now". Then create the directory for webroot challenges: ```sh mkdir -p /tmp/mnt/flash/www/.well-known/acme-challenge ``` ### Issuing certificates There's nothing Tomato-specific about this, except that you can only use webroot or DNS mode. To avoid tripping failure limits, it's best to do a dry run first by adding the `--test` flag to the command. If the dry run works, your DNS and router configurations are OK. Webroot mode: ```sh acme.sh --issue -d tomato.example.com -d www.tomato.example.com -w /tmp/mnt/flash/www ``` DNS mode (see [the guide](https://github.com/acmesh-official/acme.sh/wiki/dnsapi)): ```sh acme.sh --issue -d tomato.example.com -d www.tomato.example.com --dns dns_xxxx ``` ### Installing certificates Create a directory for your new certificate and install it there: ```sh mkdir -p /tmp/mnt/flash/cert/tomato.example.com acme.sh --install-cert -d tomato.example.com \ --fullchain-file /tmp/mnt/flash/cert/tomato.example.com/fullchain.pem \ --key-file /tmp/mnt/flash/cert/tomato.example.com/key.pem \ --reloadcmd "service enginex restart" ``` Note that Tomato has a funny quirk, internally calling nginx "enginex". Since nginx runs as user "nobody" you need to make the chain and key files readable by it. Change their owner group to "nobody" and allow group read permissions: ``` chown root:nobody /tmp/mnt/flash/cert/tomato.example.com/* chmod 0640 /tmp/mnt/flash/cert/tomato.example.com/* ``` Tomato is a single-user system, so you don't need to worry about file permissions much. Just don't put any vulnerable PHP code on the web server; leaking private keys and altering NVRAM would be pretty bad. ### Adding a reverse proxy Modify the below example to match your new hostname(s), certificate path and LAN server IP and port (on the `proxy_pass` line) and add it to the **HTTP Section** field in **Web Server→Advanced Settings**. This is a minimalist reverse proxy example, so read some guides to learn about more options, especially security-related. If the server is Tomato itself, set `proxy_pass` to _http\://127.0.0.1:80_ (match the port number with web server setting). You can add as many proxy server configurations as you wish, but note that they take up precious NVRAM, unless you move the whole nginx configuration to a file, disabling GUI settings (hint: `nginx -T`). In many cases you can leave out the `proxy_set_header` lines, as they only provide connection info for logging etc. ```nginx server { listen 443 ssl; server_name tomato.example.com www.tomato.example.com; ssl_certificate /tmp/mnt/flash/cert/tomato.example.com/fullchain.pem; ssl_certificate_key /tmp/mnt/flash/cert/tomato.example.com/key.pem; location / { proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://192.168.0.3:8080; proxy_redirect off; } } ``` Save the settings and wait for Tomato to restart nginx. You should now be able to access the LAN HTTP server from outside through _https\://tomato.example.com/_ ### Notes - Not all HTTP services are proxy-compatible. For example, absolute URLs can be troublesome, although you can fix them with [http_sub](https://nginx.org/en/docs/http/ngx_http_sub_module.html) filters. - This should be obvious, but people can be surprisingly dumb: **Don't create public proxy connections to private LAN devices/services without proper password protection.**acme.sh-0.0~git20250417.7502af3/Use-DNS-Exit-DNS-API.md000066400000000000000000000007531500024665000210470ustar00rootroot00000000000000First you need to login to your DNS Exit account to get your API Key (My Account --> My Profile -->API Key) https://dnsexit.com/Direct.sv?cmd=userApiKey export JAPI_apikey="ASKMAKM0234m23234xcdfaa" export JAPI_domain="_acme-challenge." Ok, let's issue a cert now: acme.sh --issue -d example.com --dns dns_japi The JAPI_apikey and JAPI_domain will be saved in ~/.acme.sh/account.conf and will be reused when needed.acme.sh-0.0~git20250417.7502af3/Using-pre-hook-post-hook-renew-hook-reloadcmd.md000066400000000000000000000023041500024665000264570ustar00rootroot00000000000000Those hooks are only accepted by the `--issue` command, but will be saved and apply to `--renew` or `--cron` commands as well. As such it can be a good way to do things (like close and re-open a server, or notify of updates) that need to happen only when issuance is actually attempted. ```sh acme.sh --issue -d example.com \ --pre-hook "echo this is pre hook that happens before attempting to issue a certificate." \ --post-hook "echo this is post hook that happens after attempting to issue a certificate." \ --renew-hook "echo this will be called when certs are successfully renewed." ....... ``` Note: to reload the web server when installing certificates, there is a related command: ```sh acme.sh --install-cert \ ..... \ --reloadcmd "echo this runs after successfully installing certificates." ``` Keep in mind that when running `--cron`, any newly-renewed certificates will automatically be installed, and the reloadcmd will be run. Consequently, if you are using `--pre-hook` and `--post-hook` to stop and restart a web server, you probably don't want to also reload it in reloadcmd. Since `--install-cert` is typically only run once, you can just do this by hand.acme.sh-0.0~git20250417.7502af3/Using-systemd-units-instead-of-cron.md000066400000000000000000000020161500024665000246240ustar00rootroot00000000000000**1. Create a systemd unit for acme.sh:** `/etc/systemd/system/acme_letsencrypt.service` ``` [Unit] Description=Renew Let's Encrypt certificates using acme.sh After=network-online.target nss-lookup.target [Service] Type=oneshot SyslogIdentifier=acme.sh # --home's argument should be where the acme.sh script resides. ExecStart=/path/to/acme.sh --cron --home /path/to/acme.sh ``` **2. Disable timestamps (optional):** `/path/to/acme.sh/account.conf` ``` NO_TIMESTAMP='1' ``` **3. Test that it works before creating the timer:** ``` sudo systemctl daemon-reload sudo systemctl start acme_letsencrypt journalctl -u acme_letsencrypt.service ``` **4. Create systemd timer unit for the service above:** `/etc/systemd/system/acme_letsencrypt.timer` ``` [Unit] Description=Daily renewal of Let's Encrypt's certificates [Timer] OnCalendar=daily RandomizedDelaySec=1h Persistent=true [Install] WantedBy=timers.target ``` **5. Enable timer:** ``` sudo systemctl start acme_letsencrypt.timer sudo systemctl enable acme_letsencrypt.timer ```acme.sh-0.0~git20250417.7502af3/Utilize-multiple-DNS-API-keys.md000066400000000000000000000034471500024665000232140ustar00rootroot00000000000000# How to utilize multiple DNS API keys As for now, the dns api key/secret is saved in the global `account.conf` file, so that it can be reused for any of the domains in your account. So, what if you have multiple dns api keys. The key point is to use multiple `account.conf` file. You can use either of the following ways: ## 1. Use muitlple linux users to install and use acme.sh It's the easiest way to use. You can just create multiple Linux users, and install and use acme.sh for each users: ``` su acmeuser1 curl https://get.acme.sh | sh -s email=my@example.com source ~/.acme.sh/acme.sh.env export MYDNS_APIKey1=xxxxxxx acme.sh --issue -d domain1.com --dns ........ ``` And then switch to another user: ``` su acmeuser2 curl https://get.acme.sh | sh -s email=my@example.com source ~/.acme.sh/acme.sh.env export MYDNS_APIKey2=xxxxxxx acme.sh --issue -d domain1.com --dns ........ ``` ## 2. Use multiple `--config-home` The global `account.conf` file is saved in the `--config-home` by default. So, you can use different `--config-home`. ``` curl https://get.acme.sh | sh -s email=my@example.com ``` The default config home is at `~/.acme.sh`. You can specify a custom config home on any of the acme.sh commands: ``` export MY_DNS_key2=xxxxxxx acme.sh --config-home ~/.myacme --issue -d example.com ...... ``` Every time you want to use the `MY_DNS_key2` to issue certs, you need to use the `--config-home` parameter: ``` acme.sh --config-home ~/.myacme --issue ..... acme.sh --config-home ~/.myacme --renew ...... acme.sh --config-home ~/.myacme --revoke ..... ``` You will also need to add a new crontab entry to make it renew automatically: ``` 30 0 * * * "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" --config-home "/root/.myacme" > /dev/null ``` acme.sh-0.0~git20250417.7502af3/Validity.md000066400000000000000000000055361500024665000175220ustar00rootroot00000000000000The ACME protocol supported the `NotBefore` and `NotAfter` fields of the cert. And some of the CAs supported this feature. (The Letsencrypt CA doesn't support it for now) There are 2 command options to use: 1. The `--valid-to ` option, which is for `NotAfter` field. 2. The `--valid-from ` option, which is for `NotBefore` field. Usage: ### 1. Set the lifetime of the cert: ``` acme.sh --issue -d example.com -dns dns_cf --valid-to "2022-04-01T08:10:33Z" ``` The value of `--valid-to` is an absolute date time in the future. The issued cert will expire on that time(`NotAfter`). Please be careful about the date time format, it Must be the exact format in UTC used above. You can also use a relative date time format: ``` # This cert will only be valid for `10` days. acme.sh --issue -d example.com --dns dns_cf --valid-to "+10d" # This cert will be valid for `30` hours. acme.sh --issue -d example.com --dns dns_cf --valid-to "+30h" ``` Please be careful about the format, there are only `+*d` (for days) and `+*h` (for hours) supported for now. Any other format will not be accepted. ## If you use the absolute format for `--valid-to "2022-04-01T08:10:33Z"`, the cert will NOT be renewed automatically when it expires. ## If you want the cert to be renewed automatically, please use the relative format: 1. `--valid-to +20d`(the cert will be renewed every 19 days). If the lifetime is longer than one day, it will renew at one day before. 2. `--valid-to +11h`(the cert will be renewed every 10 hours). If the lifttime is less than 24 hourst, it will renew at one hour before. ## Of course, if you don't use `--valid-to` parameter at all, the cert will be renewed every `60 days` as before. ### 2. Set the beginning time of the cert: ``` acme.sh --issue -d example.com --dns dns_cf --valid-from "2022-04-01T08:10:33Z" ``` The cert time will be valid starting from `"2022-04-01T08:10:33Z"`. You can also use the relative time format: ``` #The cert will be valid in 2 hours from now: acme.sh --issue -d example.com --dns dns_cf --valid-from "+2h" #The cert will be valid in 1 day from now: acme.sh --issue -d example.com --dns dns_cf --valid-from "+1d" ``` ### 3. You can use them both at the same time: ``` # The cert will be valid from `"2022-04-01T08:10:33Z"`, and then live for 40 days to expire: acme.sh --issue -d example.com --dns dns_cf --valid-from "2022-04-01T08:10:33Z" --valid-to "+40d" # The cert will be valid in 2 hours, and then live for 50 days to expire: acme.sh --issue -d example.com --dns dns_cf --valid-from "+2h" --valid-to "+50d" ``` ### 4. If the lifetime is measured in hours, you need to change the default crontab to run `acme.sh` every an hour: ``` 0 * * * * "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" > /dev/null ``` acme.sh-0.0~git20250417.7502af3/ZeroSSL.com-CA.md000066400000000000000000000043461500024665000202720ustar00rootroot00000000000000## Using ZeroSSL.com CA ZeroSSL doesn't have rate limits. One can issue _unlimited_ TLS/SSL certificate valid for 90 days ([ref](https://zerossl.com/letsencrypt-alternative/#acme)). Note: Since `v3`, `acme.sh` uses Zerossl as the default Certificate Authority (CA). Account registration (one-time) is required before one can issue new certs. See also: https://github.com/acmesh-official/acme.sh/wiki/Change-default-CA-to-ZeroSSL ### 1. Register your account. ##### 1a. With an email address ```bash acme.sh --register-account -m myemail@example.com --server zerossl ``` ##### 1b. With EAB credentials Alternatively, if you sign up for a [ZeroSSL account](https://app.zerossl.com/signup), bootstrap `acme.sh` with _External Account Binding_ (EAB) credentials, like so: 1. Generate your EAB credentials from https://app.zerossl.com/developer 2. Register your EAB credentials. ```bash acme.sh --register-account --server zerossl \ --eab-kid xxxxxxxxxxxx \ --eab-hmac-key xxxxxxxxx ``` Users with a ZeroSSL account can manage issued certificates from [developer console](https://zerossl.com/features/console/). ### 2. Issue certificates Use Zerossl.com with `--server zerossl`: ```bash acme.sh --server zerossl \ --issue -d example.com \ --dns dns_cf ``` If you don't want to specify `--server zerossl` every time you issue a cert, you can set `zerossl` as the default CA: ```bash acme.sh --set-default-ca --server zerossl ``` Read: https://github.com/acmesh-official/acme.sh/wiki/Server Issue any cert _from_ zerossl without having to specify `--server`: ```bash acme.sh --issue -d example.com --dns dns_cf ``` ### 3. Troubleshooting ##### Le_OrderFinalize: A KeyID must be specified If certificate issuance fails and you see something like this in the logs ```shell [XYZ 18 09:50:07 -02 2020] Create new order error. Le_OrderFinalize not found. {"type":"urn:ietf:params:acme:error:malformed","status":400,"detail":"A Key ID MUST be specified"} ``` then, re-generate your EAB credentials (refer step #2) and [re-run certificate issuance](https://github.com/acmesh-official/acme.sh/wiki/How-to-issue-a-cert). See: [acme.sh/issues/3310](https://github.com/acmesh-official/acme.sh/issues/3310#issuecomment-785374480). ---- acme.sh-0.0~git20250417.7502af3/deploy-to-docker-containers.md000066400000000000000000000102541500024665000232520ustar00rootroot00000000000000Deploy the cert/key into a docker container. There are 3 cases that acme.sh can deploy the certs into containers. 1. acme.sh is installed in the docker host machine, it deploys the certs into a container on the machine. 2. You are running `neilpang/acme.sh` container, that means acme.sh is running in a container, it can also deploy certs to another container on the same machine. 3. acme.sh is running on a machine, it deploys certs to a container running on another docker host. Lets explain one by one: ## 1. Deploy certs from docker host to a container acme.sh is installed on the docker host, it first issues a cert, then you may want to deploy the cert/key into a container. #### 1. Please set a label on the container, the label will later be used to find the container. ```sh docker run --rm -it -d --label=sh.acme.autoload.domain=example.com nginx:latest ``` #### 2. Remember the label value above, we can deploy now: ```sh # The label value to find the container export DEPLOY_DOCKER_CONTAINER_LABEL=sh.acme.autoload.domain=example.com # The target file path in the container. # The files will be copied to the position in the container. export DEPLOY_DOCKER_CONTAINER_KEY_FILE="/etc/nginx/ssl/example.com/key.pem" export DEPLOY_DOCKER_CONTAINER_CERT_FILE="/etc/nginx/ssl/example.com/cert.pem" export DEPLOY_DOCKER_CONTAINER_CA_FILE="/etc/nginx/ssl/example.com/ca.pem" export DEPLOY_DOCKER_CONTAINER_FULLCHAIN_FILE="/etc/nginx/ssl/example.com/full.pem" # The command to reload the service in the container. export DEPLOY_DOCKER_CONTAINER_RELOAD_CMD="service nginx force-reload" acme.sh --deploy --deploy-hook docker -d example.com ``` ## 2. Deploy certs from a container to another container Let's use `neilpang/acme.sh` image as an example, actually, you can use acme.sh in any container. #### 1. Ok, same as above, first run the target container with a label: ```sh docker run --rm -it -d --label=sh.acme.autoload.domain=example.com nginx:latest ``` #### 2. Run acme.sh in a container For more details see: https://github.com/Neilpang/acme.sh/wiki/Run-acme.sh-in-docker#3-run-acmesh-as-a-docker-daemon Let's run acme.sh as a daemon, a difference with the above link is that we mount docker daemon socket `/var/run/docker.sock` in to the container. ```sh docker run --rm -itd \ -v "$(pwd)/acmeout":/acme.sh \ --net=host \ --name=acme.sh \ -v /var/run/docker.sock:/var/run/docker.sock \ neilpang/acme.sh daemon ``` #### 3. Let's issue a cert first: ```sh docker exec \ -e CF_Email=xxx@exmaple.com \ -e CF_Key=xxxxxxxxxx \ acme.sh --issue -d example.com --dns dns_cf ``` #### 4. Let's deploy the cert now: ```sh docker exec \ -e DEPLOY_DOCKER_CONTAINER_LABEL=sh.acme.autoload.domain=example.com \ -e DEPLOY_DOCKER_CONTAINER_KEY_FILE=/etc/nginx/ssl/example.com/key.pem \ -e DEPLOY_DOCKER_CONTAINER_CERT_FILE="/etc/nginx/ssl/example.com/cert.pem" \ -e DEPLOY_DOCKER_CONTAINER_CA_FILE="/etc/nginx/ssl/example.com/ca.pem" \ -e DEPLOY_DOCKER_CONTAINER_FULLCHAIN_FILE="/etc/nginx/ssl/example.com/full.pem" \ -e DEPLOY_DOCKER_CONTAINER_RELOAD_CMD="service nginx force-reload" \ acme.sh --deploy -d example.com --deploy-hook docker ``` #### 5. All together, docker compose example: ```yaml version: '3.4' services: web: image: nginx container_name: nginx labels: - sh.acme.autoload.domain=example.com acme.sh: image: neilpang/acme.sh container_name: acme.sh command: daemon volumes: - ./acmeout:/acme.sh - /var/run/docker.sock:/var/run/docker.sock environment: - DEPLOY_DOCKER_CONTAINER_LABEL=sh.acme.autoload.domain=example.com - DEPLOY_DOCKER_CONTAINER_KEY_FILE=/etc/nginx/ssl/example.com/key.pem - DEPLOY_DOCKER_CONTAINER_CERT_FILE="/etc/nginx/ssl/example.com/cert.pem" - DEPLOY_DOCKER_CONTAINER_CA_FILE="/etc/nginx/ssl/example.com/ca.pem" - DEPLOY_DOCKER_CONTAINER_FULLCHAIN_FILE="/etc/nginx/ssl/example.com/full.pem" - DEPLOY_DOCKER_CONTAINER_RELOAD_CMD="service nginx force-reload" ``` ## 3. Deploy certs to a container in a remote docker host TODO: this feature is not implemented yet. If you want this feature, please create an issue, and let me know. acme.sh-0.0~git20250417.7502af3/deployhooks.md000066400000000000000000001535171500024665000203000ustar00rootroot00000000000000# Using deploy api Before you can deploy your cert, you must [issue the cert first](https://github.com/Neilpang/acme.sh/wiki/How-to-issue-a-cert). Here are the scripts to deploy the certs/key to the server/services. ## 1. Deploy the certs to your cpanel host If you want to deploy using cpanel UAPI see 7. (cpanel deploy hook is not finished yet, this is just an example.) Then you can deploy now: ```sh export DEPLOY_CPANEL_USER=myusername export DEPLOY_CPANEL_PASSWORD=PASSWORD acme.sh --deploy -d example.com --deploy-hook cpanel ``` ## 2. Deploy ssl cert on kong proxy engine based on api Before you can deploy your cert, you must [issue the cert first](https://github.com/Neilpang/acme.sh/wiki/How-to-issue-a-cert). Currently supports Kong-v0.10.x. ```sh acme.sh --deploy -d ftp.example.com --deploy-hook kong ``` It deploys to `"http://localhost:8001"` by default, you can specify the kong url to deploy: ``` export KONG_URL="http://you.kong.url:port" acme.sh --deploy -d ftp.example.com --deploy-hook kong ``` ## 3. Deploy the cert to remote server through SSH access The ssh deploy plugin allows you to deploy certificates to a remote host using SSH command to connect to the remote server. The ssh plugin is invoked with the following command... ```sh acme.sh --deploy -d example.com --deploy-hook ssh ``` Prior to running this for the first time you must tell the plugin where and how to deploy the certificates. This is done by exporting the following environment variables. This is not required for subsequent runs as the values are stored by acme.sh in the domain configuration files. Required... ``` export DEPLOY_SSH_USER=username ``` Optional... ``` export DEPLOY_SSH_CMD=custom ssh command export DEPLOY_SSH_SERVER=url or ip address of remote host export DEPLOY_SSH_KEYFILE=filename for private key export DEPLOY_SSH_CERTFILE=filename for certificate file export DEPLOY_SSH_CAFILE=filename for intermediate CA file export DEPLOY_SSH_FULLCHAIN=filename for fullchain file export DEPLOY_SSH_REMOTE_CMD=command to execute on remote host export DEPLOY_SSH_BACKUP=yes or no ``` Added in Acme release 2.8.6... ``` export DEPLOY_SSH_BACKUP_PATH=path on remote server to backup certificates export DEPLOY_SSH_MULTI_CALL=yes or no ``` **DEPLOY_SSH_USER** Username at the remote host that SSH will login with. Note that SSH must be able to login to remote host without a password... SSH Keys must have been exchanged with the remote host. Validate and test that you can login to USER@URL from the host running acme.sh before using this script. The USER@URL at the remote server must also have has permissions to write to the target location of the certificate files and to execute any commands (e.g. to stop/start services). **DEPLOY_SSH_CMD** You can customize the ssh command used to connect to the remote host. For example if you need to connect to a specific port at the remote server you can set this to, for example, "ssh -p 22" or to use `sshpass` to provide password inline instead of exchanging ssh keys (this is not recommended, using keys is more secure). Defaults to "ssh -T" **DEPLOY_SSH_SERVER** URL or IP Address of the remote server. If not provided then the domain name provided on the acme.sh --deploy command line is used. New in Acme release 2.8.7 this may be space separated list of servers to which exactly the same deploy commands can be sent. **DEPLOY_SSH_KEYFILE** Target path and filename _on the remote server_ for the private key issued by LetsEncrypt. **DEPLOY_SSH_CERTFILE** Target path and filename _on the remote server_ for the certificate issued by LetsEncrypt. If this is the same as the previous filename (for keyfile) then it is appended to the same file. **DEPLOY_SSH_CAFILE** Target path and filename _on the remote server_ for the CA intermediate certificate issued by LetsEncrypt. If this is the same as a previous filename (for keyfile or certfile) then it is appended to the same file. **DEPLOY_SSH_FULLCHAIN** Target path and filename _on the remote server_ for the fullchain certificate issued by LetsEncrypt. If this is the same as a previous filename (for keyfile, certfile or cafile) then it is appended to the same file. **DEPLOY_SSH_REMOTE_CMD** Command to execute on the remote server after copying any certificates. This could be any additional command required for example to stop and restart the service. **DEPLOY_SSH_BACKUP** Before writing a certificate file to the remote server the existing certificate will be copied to a backup directory on the remote server. By default these are placed in a hidden directory in the home directory of the SSH user ```sh ~/.acme_ssh_deploy/[domain name]-backup-[timestamp] ``` Any backups older than 180 days will be deleted when new certificates are deployed. This defaults to "yes" set to "no" to disable backup. **DEPLOY_SSH_BACKUP_PATH** Path to directory _on the remote server_ into which to backup certificates if DEPLOY_SSH_BACKUP is set to yes. Defaults to ".acme_ssh_deploy" which is a hidden directory in the home directory of the SSH user. **DEPLOY_SSH_MULTI_CALL** By default this plugin collects up all the required commands to be executed on the remote server and sends them to the remote server in a single SSH call. This fails on some target servers if the command line buffer is not long enough to hold all the data sent in SSH. This is known to affect servers using busybox. By setting this value to "yes" the certificate deployment process is split into multiple SSH calls to work around this problem. ### Examples using SSH deploy The following example illustrates deploying certificates to a QNAP NAS (tested with QTS version 4.2.3) ```sh export DEPLOY_SSH_USER="admin" export DEPLOY_SSH_KEYFILE="/etc/stunnel/stunnel.pem" export DEPLOY_SSH_CERTFILE="/etc/stunnel/stunnel.pem" export DEPLOY_SSH_CAFILE="/etc/stunnel/uca.pem" export DEPLOY_SSH_REMOTE_CMD="/etc/init.d/stunnel.sh restart" acme.sh --deploy -d qnap.example.com --deploy-hook ssh ``` Note how in this example both the private key and certificate point to the same file. This will result in the certificate being appended to the same file as the private key... a common requirement of several services. The next example illustrates deploying certificates to regular linux server with certbot and nginx installed ```sh export DEPLOY_SSH_USER="root" export DEPLOY_SSH_SERVER="example.com" export DEPLOY_SSH_KEYFILE="/etc/letsencrypt/archive/example.com/privkey2.pem" export DEPLOY_SSH_FULLCHAIN="/etc/letsencrypt/archive/example.com/fullchain2.pem" export DEPLOY_SSH_CAFILE="/etc/letsencrypt/archive/example.com/cert2.pem" export DEPLOY_SSH_REMOTE_CMD="systemctl restart nginx" acme.sh --deploy -d example.com --deploy-hook ssh ``` The next example illustrates deploying certificates to a Unifi Controller (tested with version 5.12.72). ```sh export DEPLOY_SSH_USER="root" export DEPLOY_SSH_SERVER="unifi.example.com" export DEPLOY_SSH_KEYFILE="/var/lib/unifi/unifi.example.com.key" export DEPLOY_SSH_FULLCHAIN="/var/lib/unifi/unifi.example.com.cer" export DEPLOY_SSH_REMOTE_CMD="DIR=/var/lib/unifi && FQDN=unifi.example.com \ && openssl pkcs12 -export \ -inkey $DIR/$FQDN.key -in $DIR/$FQDN.cer -out $DIR/$FQDN.p12 \ -name unifi -password pass:aircontrolenterprise \ && keytool -delete -alias unifi -keystore $DIR/keystore \ -deststorepass aircontrolenterprise \ && keytool -importkeystore -deststorepass aircontrolenterprise \ -destkeypass aircontrolenterprise \ -destkeystore $DIR/keystore -srckeystore /$DIR/$FQDN.p12 \ -srcstoretype PKCS12 -srcstorepass aircontrolenterprise -alias unifi -noprompt \ && chown -R unifi:unifi $DIR/keystore && service unifi restart" export DEPLOY_SSH_MULTI_CALL="yes" acme.sh --deploy -d unifi.example.com --deploy-hook ssh ``` In this example we execute several commands on the remote host after the certificate files have been copied... to generate a pkcs12 file compatible with Unifi, to import it into the Unifi keystore and then finally to restart the service. Note also that once the certificate is imported into the keystore the individual certificate files are no longer required. We could if we desired delete those files immediately. If we do that then we should disable backup at the remote host (as there are no files to backup -- they were erased during deployment). For example... ```sh export DEPLOY_SSH_BACKUP=no # modify the end of the remote command... && rm /var/lib/unifi/unifi.example.com.key \ /var/lib/unifi/unifi.example.com.cer \ /var/lib/unifi/unifi.example.com.p12 \ && service unifi restart ``` The next example illustrates deploying certificates to VMware ESXi (tested with version 6.7u3). Requires Acme 2.8.6 or later. Note that by default ESXi hosts have ssh access disabled and VMware recommends only enabling it if necessary for administrative purposes - displaying a warning notice on the ESXi web interface. You must enable ssh on ESXi and have exchanged ssh keys for this deploy hook to work. ```sh export DEPLOY_SSH_USER="root" export DEPLOY_SSH_SERVER="vmwareesxi.example.com" export DEPLOY_SSH_KEYFILE="/etc/vmware/ssl/rui.key" export DEPLOY_SSH_FULLCHAIN="/etc/vmware/ssl/rui.crt" export DEPLOY_SSH_REMOTE_CMD="/etc/init.d/hostd restart" export DEPLOY_SSH_MULTI_CALL="yes" acme.sh --deploy -d vmwareesxi.example.com --deploy-hook ssh ``` ## 4. Deploy the cert to local vsftpd server ```sh acme.sh --deploy -d ftp.example.com --deploy-hook vsftpd ``` The default vsftpd conf file is `/etc/vsftpd.conf`, if your vsftpd conf is not in the default location, you can specify one: ```sh export DEPLOY_VSFTPD_CONF="/etc/vsftpd.conf" acme.sh --deploy -d ftp.example.com --deploy-hook vsftpd ``` The default command to restart vsftpd server is `service vsftpd restart`, if it doesn't work, you can specify one: ```sh export DEPLOY_VSFTPD_RELOAD="/etc/init.d/vsftpd restart" acme.sh --deploy -d ftp.example.com --deploy-hook vsftpd ``` ## 5. Deploy the cert to local exim4 server ```sh acme.sh --deploy -d ftp.example.com --deploy-hook exim4 ``` The default exim4 conf file is `/etc/exim/exim.conf`, if your exim4 conf is not in the default location, you can specify one: ```sh export DEPLOY_EXIM4_CONF="/etc/exim4/exim4.conf.template" acme.sh --deploy -d ftp.example.com --deploy-hook exim4 ``` The default command to restart exim4 server is `service exim4 restart`, if it doesn't work, you can specify one: ```sh export DEPLOY_EXIM4_RELOAD="/etc/init.d/exim4 restart" acme.sh --deploy -d ftp.example.com --deploy-hook exim4 ``` ## 6. Deploy the cert to OSX Keychain ```sh acme.sh --deploy -d ftp.example.com --deploy-hook keychain ``` ## 7. Deploy to cpanel host using UAPI This hook is using UAPI and works in cPanel & WHM version 56 or newer. ``` acme.sh --deploy -d example.com --deploy-hook cpanel_uapi ``` DEPLOY_CPANEL_USER is required only if you run the script as root and it should contain cpanel username. ```sh export DEPLOY_CPANEL_USER=username acme.sh --deploy -d example.com --deploy-hook cpanel_uapi ``` Please note, that the cpanel_uapi hook will deploy only the first domain when your certificate will automatically renew. Therefore you should issue a separate certificate for each domain. ## 8. Deploy the cert to your FRITZ!Box router You must specify the credentials that have administrative privileges on the FRITZ!Box in order to deploy the certificate, plus the URL of your FRITZ!Box, through the following environment variables: ```sh $ export DEPLOY_FRITZBOX_USERNAME=my_username $ export DEPLOY_FRITZBOX_PASSWORD=the_password $ export DEPLOY_FRITZBOX_URL=https://fritzbox.example.com ``` After the first deployment, these values will be stored in your $HOME/.acme.sh/account.conf. You may now deploy the certificate like this: ```sh acme.sh --deploy -d fritzbox.example.com --deploy-hook fritzbox ``` ## 9. Deploy the cert to strongswan ```sh acme.sh --deploy -d ftp.example.com --deploy-hook strongswan ``` ## 10. Deploy the cert to HAProxy You must specify the path where you want the concatenated key and certificate chain written. ```sh export DEPLOY_HAPROXY_PEM_PATH=/etc/haproxy ``` You may optionally define the command to reload HAProxy. If you don't set this environment variable, a no-op command (`true`) is used, which will show success, but _will not_ reload HAProxy. **It is strongly recommended to set this something that makes sense for your distro.** ```sh export DEPLOY_HAPROXY_RELOAD="/usr/sbin/service haproxy restart" ``` You can then deploy the certificate as follows ```sh acme.sh --deploy -d haproxy.example.com --deploy-hook haproxy ``` The path for the PEM file will be stored with the domain configuration and will be available when renewing, so that deploy will happen automatically when renewed. It is also possible to do hot updates, without any reload, using the HAProxy stats socket. To achieve that, `DEPLOY_HAPROXY_HOT_UPDATE=yes` must be used, as well as the `DEPLOY_HAPROXY_STATS_SOCKET` variable with the path of the stats socket. HAProxy must be configured with a `crt` directory which will be also set in `DEPLOY_HAPROXY_PEM_PATH` ``` DEPLOY_HAPROXY_HOT_UPDATE=yes DEPLOY_HAPROXY_STATS_SOCKET=UNIX:/var/run/haproxy/admin.sock DEPLOY_HAPROXY_PEM_PATH=/etc/haproxy/certs acme.sh --deploy -d domain1.com --deploy-hook haproxy ``` A more complete tutorial is available on the [haproxy wiki](https://github.com/haproxy/wiki/wiki/Letsencrypt-integration-with-HAProxy-and-acme.sh) ## 11. Deploy your cert to Gitlab pages You must define the API key and the informations for the project and Gitlab page you are updating the certificate for. ```sh # The token can be created in your user settings under "Access Tokens" export GITLAB_TOKEN="xxxxxxxxxxx" # The project ID is displayed on the home page of the project export GITLAB_PROJECT_ID=12345678 # The domain must match the one defined for the Gitlab page, without "https://" export GITLAB_DOMAIN="www.mydomain.com" ``` You can then deploy the certificate as follows ```sh acme.sh --deploy -d www.mydomain.com --deploy-hook gitlab ``` ## 12. Deploy your cert to Hashicorp Vault ```sh export VAULT_PREFIX="acme" ``` You can then deploy the certificate as follows ```sh acme.sh --deploy -d www.mydomain.com --deploy-hook vault_cli ``` Your certs will be saved in Vault using this structure: ```sh vault write "${VAULT_PREFIX}/${domain}/cert.pem" value=@"..." vault write "${VAULT_PREFIX}/${domain}/cert.key" value=@"..." vault write "${VAULT_PREFIX}/${domain}/chain.pem" value=@"..." vault write "${VAULT_PREFIX}/${domain}/fullchain.pem" value=@"..." ``` You might be using Fabio load balancer (which can get certs from Vault). It needs a bit different structure of your certs in Vault. It gets certs only from keys that were saved in `prefix/domain`, like this: ```bash vault write /www.domain.com cert=@cert.pem key=@key.pem ``` If you want to save certs in Vault this way just set "FABIO" env variable to anything (ex: "1") before running `acme.sh`: ```sh export FABIO="1" ``` If you are using **v2** of the **kv** api then set the `VAULT_KV_V2` environment variable to anything (ex: "1") before running `acme.sh` (do not forget to change VAULT_PREFIX as well) ```sh export VAULT_KV_V2="1" ``` You can also use `--deploy-hook vault` instead of `vault_cli`. In that case Vault's HTTP API will be used allowing you to use Docker image for deployment without Vault binary. Another ENV variable is needed for `vault` ```sh export VAULT_ADDR=http://localhost:8200 # no slash at the end ``` ## 13. Deploy your certificate to Qiniu.com 使用 acme.sh 部署到七牛之前，需要确保部署的域名已打开 HTTPS 功能，您可以访问[融合 CDN - 域名管理](https://portal.qiniu.com/cdn/domain) 设置。 另外还需要先导出 AK/SK 环境变量，您可以访问[密钥管理](https://portal.qiniu.com/user/key) 获得。 ```sh $ export QINIU_AK="foo" $ export QINIU_SK="bar" ``` 完成准备工作之后，您就可以通过下面的命令开始部署 SSL 证书到七牛上： ```sh $ acme.sh --deploy -d example.com --deploy-hook qiniu ``` 假如您部署的证书为泛域名证书，您还需要设置 `QINIU_CDN_DOMAIN` 变量，指定实际需要部署的域名(请注意泛域名前的点)： ```sh $ export QINIU_CDN_DOMAIN=".cdn.example.com" $ acme.sh --deploy -d example.com --deploy-hook qiniu ``` 假如需要部署多个域名, 使用空格将域名分隔开来: ```sh $ export QINIU_CDN_DOMAIN="cdn1.example.com cdn2.example.com" $ acme.sh --deploy -d example.com --deploy-hook qiniu ``` ### English version You should create AccessKey/SecretKey pair in https://portal.qiniu.com/user/key before deploying your certificate, and please ensure you have enabled HTTPS for your domain name. You can enable it in https://portal.qiniu.com/cdn/domain. ```sh $ export QINIU_AK="foo" $ export QINIU_SK="bar" ``` then you can deploy certificate by following command: ```sh $ acme.sh --deploy -d example.com --deploy-hook qiniu ``` (Optional), If you are using wildcard certificate, you may need export `QINIU_CDN_DOMAIN` to specify which domain you want to update (please note the leading dot): ```sh $ export QINIU_CDN_DOMAIN=".cdn.example.com" $ acme.sh --deploy -d example.com --deploy-hook qiniu ``` If you want to deploy more than one domain, just use space to splite them: ```sh $ export QINIU_CDN_DOMAIN="cdn1.example.com cdn2.example.com" $ acme.sh --deploy -d example.com --deploy-hook qiniu ``` ## 14. Deploy your cert on MyDevil.net Once you have acme.sh installed and certificate issued (see info in [DNS API](https://github.com/Neilpang/acme.sh/wiki/dnsapi#66-use-mydevilnet)), you can install it by following command: ```sh acme.sh --deploy --deploy-hook mydevil -d example.com ``` That will remove old certificate and install new one. ## 15. Deploy your cert to local mailcow server You can install your certificates to a local [mailcow](https://github.com/mailcow/mailcow-dockerized/) instance. The deploy hook will copy the certificates and reload the containers, that use the certificates (`postfix-mailcow` `dovecot-mailcow` and `nginx-mailcow`). ```sh $ export DEPLOY_MAILCOW_PATH="/path/to/mailcow" $ acme.sh --deploy -d example.com --deploy-hook mailcow ``` The default command to restart is `docker-compose restart postfix-mailcow dovecot-mailcow nginx-mailcow`, if you want a custom restart command, specify it by setting `DEPLOY_MAILCOW_RELOAD`: ```sh $ export DEPLOY_MAILCOW_PATH="/path/to/mailcow" $ export DEPLOY_MAILCOW_RELOAD="docker-compose restart" $ acme.sh --deploy -d example.com --deploy-hook mailcow ``` ## 16. Deploy the cert to G-Core CDN service Deploy the cert to G-Core CDN service (https://gcorelabs.com/ru/) using the G-Core Labs API (https://docs.gcorelabs.com/cdn/). Then you can deploy now: ```sh export DEPLOY_GCORE_CDN_USERNAME=myusername export DEPLOY_GCORE_CDN_PASSWORD=mypassword acme.sh --deploy -d example.com --deploy-hook gcore_cdn ``` ## 17. Deploy the cert to remote routeros ```sh acme.sh --deploy -d ftp.example.com --deploy-hook routeros ``` Before you can deploy the certificate to router os, you need to add the id_rsa.pub key to the routeros and assign a user to that key. The user need's to have the following policies enabled: ssh, ftp, read, write, password and sensitive. There are no need to enable ftp service for the script to work, as they are transmitted over SCP, however ftp is needed to store the files on the router. Then you need to set the environment variables for the deploy script to work. ```sh export ROUTER_OS_USERNAME=certuser export ROUTER_OS_HOST=router.example.com export ROUTER_OS_PORT=22 acme.sh --deploy -d ftp.example.com --deploy-hook routeros ``` The deploy script will remove previously deployed certificates, and it does this with an assumption on how RouterOS names imported certificates, adding a "cer_0" suffix at the end. This is true for versions 6.32 -> 6.41.3 and 7.1.3, but it is not guaranteed that it will be true for future versions when upgrading. If the router have other certificates with the same name as the one beeing deployed, then this script will remove those certificates. At the end of the script, the services that use those certificates could be updated. Currently only the www-ssl service is beeing updated, but more services could be added. For instance: ```sh export ROUTER_OS_ADDITIONAL_SERVICES="/ip service set api-ssl certificate=$_cdomain.cer_0" ``` returns 0 means success, otherwise error. To adopt parameters to `scp` and/or `ssh` set the optional `ROUTER_OS_SSH_CMD` and `ROUTER_OS_SCP_CMD` variables accordingly, see ssh(1) and scp(1) for parameters to those commands. Example: ```sh export ROUTER_OS_SSH_CMD="ssh -i /acme.sh/.ssh/router.example.com -o UserKnownHostsFile=/acme.sh/.ssh/known_hosts" export ROUTER_OS_SCP_CMD="scp -i /acme.sh/.ssh/router.example.com -o UserKnownHostsFile=/acme.sh/.ssh/known_hosts" ```` If there are any bugs for routeros hook, please report here: https://github.com/Neilpang/acme.sh/issues/2344 ## 18. Deploy the cert into docker containers. See: https://github.com/Neilpang/acme.sh/wiki/deploy-to-docker-containers ## 19. Deploy the cert into Palo Alto Networks Firewall. In PAN-OS 9.1+ create a new admin role with API permissions to import and commit. Create a user that will only be used for the purpose of deploying certs. Assign this user to the role you created. For prior versions of PAN-OS the admin must have superuser access to upload the private key. ``` export PANOS_USER="your_cert_user" export PANOS_PASS="your_password" export PANOS_HOST="10.0.0.1" // Replace with Firewall/Panorama Host # optional export PANOS_TEMPLATE="" #Template Name of panorama managed devices acme.sh --deploy -d example.com --deploy-hook panos --insecure ``` **Note:** after a successful deploy you can remove these environment variables as they will be stored by acme.sh. If the password for the user changes you will need to set the variables again. You can also remove --insecure if you deployed a cert and configured it as management cert. ## 20. Deploy the certificate to Synology DSM As pointed out [inside the deploy script file](https://github.com/acmesh-official/acme.sh/blob/ff090d2f74f994da4bca89b942b08bb714b25a46/deploy/synology_dsm.sh#L11-L38) itself, only 3 simple steps are required for deploy: 1. Set the required environment variables which used for authentication while deploying: - (Recommend) Use an automatically created temp admin user by executing `export SYNO_USE_TEMP_ADMIN=1`. In this way, you won't need to provide any admin credentials, the deploy script itself will utilize Synology built-in utils to complete authentication, so it designed to only support locally deployment, and can't be used to deploy in docker or deploy remotely. After deploy script exits, the temp admin user should either not have been created or has already been deleted, however it may still remain if script exits unexpectedly (e.g., aborted by pressing "Ctrl+C"), in this case, you can safely delete it via "Control Panel". - Use your existing admin user by provide its credential (username, password, OTP): 1. Execute `export SYNO_USERNAME="adminUser"` where `adminUser` is any user with sufficient administrative rights, e. g. `admin`. 2. Execute `export SYNO_PASSWORD="adminPassword"` where `adminPassword` is the chosen user's password. Script will load previous saved conf for subsequent deployments, so if you used to use temp admin method and want to change to deploy with existing admin user, you need to execute `export CLEAR_SYNO_USE_TEMP_ADMIN=1` first. 2. Set optional environment variables, if you won't need to change the defaults, then just skip this step, all optional exports are as the following (shown values are the examples): - common optional variables ``` - export SYNO_SCHEME="http" - defaults to "http" - export SYNO_HOSTNAME="localhost" - defaults to "localhost" - export SYNO_PORT="5000" - defaults to "5000" - export SYNO_CREATE=1 - to allow creating the cert if it doesn't exist - export SYNO_CERTIFICATE="" - to replace a specific cert by its description ``` - temp admin 2FA-OTP optional variables ``` - export SYNO_LOCAL_HOSTNAME=1 - if set to 1, force to treat hostname is targeting current local machine (since this method only locally supported) ``` - existing admin 2FA-OTP optional variables ``` - export SYNO_OTP_CODE="XXXXXX" - if set, script won't require to interactive input the OTP code - export SYNO_DEVICE_NAME="CertRenewal" - if set, script won't require to interactive input the device name - export SYNO_DEVICE_ID="" - (deprecated, auth with OTP code instead) required for omitting 2FA-OTP ``` 3. Execute the command `acme.sh --deploy --deploy-hook synology_dsm -d example.com` to deploy the certificate for `example.com` to your DSM. ### About the authentication > If you installed `acme.sh` in DSM rather than docker, and executed `export SYNO_USE_TEMP_ADMIN=1`, feel free to skip this section, because we won't need your own credential at all. BTW, if your DSM lost the required built-in tools to create temp admin user, the script will let you know, so you can back here to learn more. > > We highly recommand you to choose the temp user method if avaiable, so you won't need to provide any of your own DSM credential, and the script won't need to store related credential (in plaintext) on your disk. For accessing the DSM successfully, the script will require you to provide your admin user credential (username & password), you can do it by exporting them, and for the future automatic execution, the script will save them in your disk (in plaintext). In recent DSM versions, Synology requires 2-factor authentication enabled for admin users, and requires the user to input TOTP (Time-based One Time Password) code for each API-based access, so the deprecated (still available for backward compatibility) setup requires `SYNO_TOTP_SECRET`, it will be provided to `oathtool` to get the code. However, this method has many flaws: - requires the user to manually install `oathtool` in DSM, since it's not included in the DSM built-in toolkit. - require the user to provide their TOTP **SECRET**, it will be provided to the third party CLI tool every time we execute the script, and will be saved (in plaintext) on user's disk. The **new** setup method won't require generating TOTP each time - TOTP can be omitted by utilizing so-called parameter "device ID". In the early version of the deployment script, the users need to get it like a pro - its a cookie value leisurely stored in their browser, usually via devtools, then execute `export SYNO_DEVICE_ID=""`. After a few updates, we simplified the process, so we can now act as the same as we are on web UI while deploying - script will require you to input the TOTP code for the admin user (defined by `SYNO_USERNAME`) only once, and will require you to input the device name for verifaction (`CertRenewal` by default), then obtain to store the "device ID" info (still in plaintext) to your local configuration file, which can be used upon subsequent deployments. If you don't want to interactive input the info, you can just excute `export SYNO_OTP_CODE="XXXXXX"` and `export SYNO_DEVICE_NAME="CertRenewal"` for the above steps. ### Additional optional parameters It's recommended to set `SYNO_SCHEME` to `https`, `SYNO_PORT` to `5001` and `SYNO_HOSTNAME` to your actual DSM's domain (e.g., `nas.example.com`) instead of the defaults. Which increased security by TLS-based connection. However, using `https` & `localhost` may require addition of the [`--insecure` command line argument](https://github.com/acmesh-official/acme.sh/wiki/Options-and-Params) to successfully deploy the certificate to DSM: ```sh acme.sh --deploy --insecure --deploy-hook synology_dsm -d example.com ``` Though, enabling HTTP/2 still might give you a `curl 16 error` warning, although the script succeeded anyways. Additionally, if you choose to use temp admin user method, and to prevent confusion, the value of `SYNO_HOSTNAME` must targets to current local machine (e.g., `localhost` or `127.0.0.1`), however if your custom SYNO_HOSTNAME does indeed target to current local machine, you can execute `export SYNO_LOCAL_HOSTNAME=1` to explicitly declare it before deploying. When issuing a certificate (e.g., Let's Encrypt) for the first time instead of renewing it, `export SYNO_CREATE=1` must be executed once. Any subsequent run won't need that variable, hence it's not saved within your configuration file at all. `SYNO_CERTIFICATE` is set as empty string by default, so the script will replace "default synology certificate" by your domain certificate, it should be all fine. however if you don't want to do so, you can always change it's value to anything you want to describe the certificate. The deployed certificate should show up inside `Control Panel` -> `Security` -> `Certificates`, it can be assigned to specific services (or set as the default certificate). ## 21. Deploy the cert to OpenStack Barbican This provider supports [OpenStack Barbican](https://docs.openstack.org/barbican) secret manager. Report any issues to https://github.com/acmesh-official/acme.sh/issues/3056 This provider requires the OpenStack Client (python-openstackclient) and Barbican client (python-barbicanclient) be installed and available in your path. It also requires you use Keystone V3 credentials, which can be either password or application credentials provided as environment variables. You will most likely want to source your OpenStack RC file to set your environment variables: ``` . openrc.sh ``` or manually like: ``` export OS_AUTH_URL=https://keystone.example.com:5000/ export OS_USERNAME= export OS_PASSWORD= export OS_PROJECT_NAME= export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=Default ``` To deploy a cert: ``` acme.sh --deploy -d example.com --deploy-hook openstack ``` Your OpenStack credentials will be saved to `~/.acme.sh/account.conf`. ## 22. Deploy the cert to CleverReach Report any issues to https://github.com/acmesh-official/acme.sh/issues/3276 For this provider you need a OAuth App. You can create it at https://eu.cleverreach.com/admin/account_rest.php. Make sure that at least the "SSL" scope is checked. Please ensure that your domain for the cert. is already added to your account. After this set the following variables: ```sh export DEPLOY_CLEVERREACH_CLIENT_ID="Your CleverReach OAuth Client ID" export DEPLOY_CLEVERREACH_CLIENT_SECRET="Your CleverReach OAuth Client Secret" ``` To deploy the cert now run: ```sh acme.sh --deploy -d example.com --deploy-hook cleverreach ``` Now the cert is added to all domains that are covered by it. If you are an agency and want to deploy a certificate to a subaccount of yours you add set following additional variable: ```sh export DEPLOY_CLEVERREACH_SUBCLIENT_ID="Desired subaccount Client ID (not OAuth Client ID)" ``` For the required rights please contact the CleverReach support. ## 23. Deploy the cert on a Unifi Controller or Cloud Key The unifi deploy hook supports self-hosted Unifi Controller, Unifi Cloud Key (Gen1/2/2+), and Unifi Cloud Key running UnifiOS (v2.0.0+, Gen2/2+ only). Full support for Cloud Key devices is available in acme.sh v2.8.9 or later. These instructions are for running acme.sh locally on the Unifi Controller machine or on a Unifi Cloud Key device. If you run acme.sh on a remote machine, follow the Unifi examples under [ssh deploy](#examples-using-ssh-deploy) instead. Report any issues to https://github.com/acmesh-official/acme.sh/issues/3359 To deploy the cert run: ```sh acme.sh --deploy -d example.com --deploy-hook unifi ``` You may see a warning about "Overwriting existing alias unifi in destination keystore" or that "the JKS keystore uses a proprietary format." Both can be ignored. The "service unifi restart" step may take a minute or more as it reloads the Unifi Controller. On a Unifi Cloud Key, acme.sh installations and configuration seem to survive firmware upgrades when installed in the default location (/root/.acme.sh). But the renewal cron job may be lost after some firmware upgrades; use `crontab -l` to check, and re-install with `acme.sh --install-cronjob` if necessary. The unifi deploy hook automatically detects supported Unifi environments, and should not need additional configuration. However, if you have a non-standard (self hosted) Unifi Controller installation, you may need to set some variables before running the deploy hook the first time, e.g: ```sh export DEPLOY_UNIFI_KEYSTORE="/path/to/custom/java/keystore" ``` See the comments at the top of [unifi.sh](https://github.com/acmesh-official/acme.sh/blob/master/deploy/unifi.sh) for a list of settings. (Most users should not need to do this.) ## 24. Deploy the cert into a Peplink router ```sh # Required settings export PEPLINK_Hostname="192.168.0.1" export PEPLINK_Username="Peplink_Admin_Username" export PEPLINK_Password="Peplink_Admin_Password" # Optional settings (and default values) # export PEPLINK_Certtype="webadmin" # The type of certificate in "Network" -> "Certificate Manager". Possible options are: "chub" (ContentHub), "openvpn" (OpenVPN CA), "portal" (Captive Portal SSL),"webadmin" (Web Admin SSL), "webproxy" (Proxy Root CA), "wwan_ca" (Wi-Fi WAN CA), "wwan_client" (Wi-Fi WAN Client) # export PEPLINK_Scheme="https" # Can be set to HTTP, defaults to HTTPS # export PEPLINK_Port="443" # Port of Peplink WebUI, defaults to 443 acme.sh --deploy -d example.com --deploy-hook peplink ``` When using https to connect to the Web UI with an existing self-signed certificate (e.g. the default certificate) we need to add the --insecure option to the deploy command. refer to [https://github.com/acmesh-official/acme.sh/wiki/Options-and-Params]. ```sh acme.sh --insecure --deploy -d example.com --deploy-hook peplink ``` The certificate should now show up in "Network" -> "Certificate Manager". ## 25. Deploy the cert on TrueNAS Core Server The deploy script supports TrueNAS Core 12.0-U3 or higher. The generally recommended deployment method is to run acme.sh on the TrueNAS server itself via the built-in cron facility, using the DNS API mode to authenticate to LetsEncrypt. Almost all TrueNAS servers are not (and should not be) exposed directly to the Internet, so authenticating to LetsEncrypt via the HTTP-01 challenge type is usually not feasible. (The locked-down nature of the TrueNAS web interface also makes it difficult. While it is possible to set a non-standard HTTP port for the web interface, you would still need to set up an additional HTTP server daemon (preferably in a jail) and redirect port 80 to your new HTTP daemon. You will also need to add the non-standard port number to the end of the DEPLOY_TRUENAS_HOSTNAME value. Since most DNS providers now have APIs this is a lot of unnecessary custom work that can be avoided by just using the DNS API approach.) Before doing the deployment, you will need to generate an API Key for the server. In the TrueNAS web interface you can click on the gear wheel in the top right corner, then select API Keys from the menu. Carefully record the API Key since it will only be shown once. The script uses the following environment variables, which only need to be set during the initial run. (The acme.sh deployment framework will store their values automatically for subsequent runs.) ``` DEPLOY_TRUENAS_APIKEY="" # Required DEPLOY_TRUENAS_HOSTNAME="localhost" # Optional, defaults to localhost DEPLOY_TRUENAS_SCHEME="http" # Optional, defaults to http, set alternatively to https ``` If you run acme.sh on a system other than the TrueNAS server then you will need to set the DEPLOY_TRUENAS_HOSTNAME to the IP or Hostname of the TrueNAS server. If the setting "Web Interface HTTP -> HTTPS-Redirect" in the TrueNAS web interface is checked then DEPLOY_TRUENAS_SCHEME will be set to https by default. ``` acme.sh --insecure --deploy -d truenas.example.com --deploy-hook truenas ``` ## 26. Deploy the cert on OpenMediaVault (OMV) This deploy script is tested on OpenMediaVault 5.x. It supports both local and remote deployment. The way it works is that if a cert with the matching domain name is not found, it will firstly create a dummy cert to get its uuid, and then replace it with your cert. ``` export DEPLOY_OMV_WEBUI_ADMIN="admin" export DEPLOY_OMV_HOST="192.168.1.200" export DEPLOY_OMV_SSH_USER="root" ``` **DEPLOY_OMV_WEBUI_ADMIN** This is OMV web gui admin account. Default value is admin. It's required as the user parameter (-u) for the omv-rpc command. **DEPLOY_OMV_HOST** and **DEPLOY_OMV_SSH_USER** are optional. They are used for remote deployment through ssh (support public key authentication only). Per design, OMV web gui admin doesn't have ssh permission, so another account is needed for ssh. ```sh acme.sh --deploy -d omv.example.com --deploy-hook openmediavault ``` ## 27. Deploy the cert on a Proxmox VE node. This deploy script is tested on Proxmox Virtual Environment 7.2-4. It deploys a certificate through the Proxmox VE API, it requires an API key with access to the [sys.modify](https://pve.proxmox.com/pve-docs/api-viewer/index.html#/nodes/{node}/certificates/custom) permission. To create an API key with the sys.modify permission either create an API key as root _or_ create a new user with the sys.modify permission and create an API key for that user then, when creating the API key, ensure that the `Privilege Separation` box is unchecked (to inherit permissions from the user) _or_ assign the sys.modify permission directly to the API token. Make note of the `Token ID` as that will be used as the value for **DEPLOY_PROXMOXVE_API_TOKEN_NAME**, and make note of the token key itself as that is required and will be used for **DEPLOY_PROXMOXVE_API_TOKEN_KEY**, the API token key can only be seen _once_ at initial creation and not viewed again afterwards. When creating a new user make note of the _username_ and _realm_ (the string after the `@`). The username will be used as the value for **DEPLOY_PROXMOXVE_USER** and the realm will be used as the value for **DEPLOY_PROXMOXVE_USER_REALM**. **DEPLOY_PROXMOXVE_SERVER**: The hostname of the proxmox ve node. Defaults to the domain of the certificate.\ **DEPLOY_PROXMOXVE_SERVER_PORT**: The port number the management interface is on. Defaults to 8006.\ **DEPLOY_PROXMOXVE_NODE_NAME**: The name of the node we will be connecting to. Defaults to the host portion of the server fqdn.\ **DEPLOY_PROXMOXVE_USER**: The user who owns the API key. Defaults to root.\ **DEPLOY_PROXMOXVE_USER_REALM**: The authentication realm the user authenticates with. Defaults to pam.\ **DEPLOY_PROXMOXVE_API_TOKEN_NAME**: The name of the API token created for the user account. Defaults to acme.\ **DEPLOY_PROXMOXVE_API_TOKEN_KEY**: The API token. Required. ```sh export DEPLOY_PROXMOXVE_USER= export DEPLOY_PROXMOXVE_USER_REALM= export DEPLOY_PROXMOXVE_API_TOKEN_NAME= export DEPLOY_PROXMOXVE_API_TOKEN_KEY= acme.sh --deploy -d vm1.home.wesitcllc.com --deploy-hook proxmoxve ``` ## 27bis. Deploy the cert on a Proxmox Backup Server (PBS). This deploy script is tested on Proxmox Backup Server 3.3-2. It deploys a certificate through the Proxmox Backup Server API, it requires an API key with access to the [sys.modify](https://pbs.proxmox.com/docs/api-viewer/index.html#/nodes/%7Bnode%7D/certificates/custom) permission. To create an API key with the sys.modify permission either create an API key as root _or_ create a new user with the sys.modify permission and create an API key for that user then, when creating the API key, ensure that the `Privilege Separation` box is unchecked (to inherit permissions from the user) _or_ assign the sys.modify permission directly to the API token. Make note of the `Token ID` as that will be used as the value for **DEPLOY_PROXMOXBS_API_TOKEN_NAME**, and make note of the token key itself as that is required and will be used for **DEPLOY_PROXMOXBS_API_TOKEN_KEY**, the API token key can only be seen _once_ at initial creation and not viewed again afterwards. When creating a new user make note of the _username_ and _realm_ (the string after the `@`). The username will be used as the value for **DEPLOY_PROXMOXBS_USER** and the realm will be used as the value for **DEPLOY_PROXMOXBS_USER_REALM**. **DEPLOY_PROXMOXBS_SERVER**: The hostname of the proxmox backup server. Defaults to the domain of the certificate.\ **DEPLOY_PROXMOXBS_SERVER_PORT**: The port number the management interface is on. Defaults to 8007.\ **DEPLOY_PROXMOXBS_USER**: The user who owns the API key. Defaults to root.\ **DEPLOY_PROXMOXBS_USER_REALM**: The authentication realm the user authenticates with. Defaults to pam.\ **DEPLOY_PROXMOXBS_API_TOKEN_NAME**: The name of the API token created for the user account. Defaults to acme.\ **DEPLOY_PROXMOXBS_API_TOKEN_KEY**: The API token. Required. ```sh export DEPLOY_PROXMOXBS_USER= export DEPLOY_PROXMOXBS_USER_REALM= export DEPLOY_PROXMOXBS_API_TOKEN_NAME= export DEPLOY_PROXMOXBS_API_TOKEN_KEY= acme.sh --deploy -d pbs.home.wesitcllc.com --deploy-hook proxmoxbs ``` ## 28. Deploy cert on MuleSoft CloudHub 2.0 Before you can deploy your cert, you must [issue the cert first](https://github.com/Neilpang/acme.sh/wiki/How-to-issue-a-cert). This script deploys an SSL certificate on [CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/) using Anypoint Platform REST APIs via curl. This script uses a [Connected App - Client Credentials](https://docs.mulesoft.com/access-management/connected-apps-developers#developers). The App must have "Cloudhub Network Administrator" or "Cloudhub Organization Admin" scope. A [TLS Context](https://docs.mulesoft.com/cloudhub-2/ps-config-domains) is automatically created into the Private Space and the certificate is deployed on it. The following environment variables are required to execute this script: * **CH2_CLIENT_ID** - Connected App Client ID\ * **CH2_CLIENT_SECRET** - Connected App Client Secret\ * **ORGANIZATION_ID** - Anypoint Platform Organization ID\ * **CH2_PRIVATE_SPACE_ID** - Private Space ID where the TLS Context will be created ``` export CH2_CLIENT_ID= export CH2_CLIENT_SECRET= export ORGANIZATION_ID= export CH2_PRIVATE_SPACE_ID= ``` Deploy the cert using the following: ``` acme.sh --deploy -d 'my-cert.acme-apis.com' --deploy-hook cloudhub_v2 ``` ## 29. Deploy your cert to CacheFly You must visit the [CacheFly Control Panel](https://portal.cachefly.com/app/tokens) and create an API Token before getting started. Then you need to set the environment variables for the deploy script to work. ```sh export CACHEFLY_TOKEN="Your CacheFly API Token" acme.sh --deploy -d example.com --deploy-hook cachefly ``` ## 30. Deploy your cert to Edgio You must define the API CLIENT ID, API CLIENT SECRET and ENVIRONMENT ID before getting started. To create an API client ([Documentation](https://docs.edg.io/applications/v7/develop/rest_api/authentication#administering-api-clients)), and assign the 'app.config' scope. To get the Environment ID, navigate to the Property and Environment pages where the certificate is to be deployed. Once there, you can find the Environment ID within the 'Environment Settings'. ```sh export EDGIO_CLIENT_ID="Your Edgio Client ID" export EDGIO_CLIENT_SECRET="Your Edgio Client Secret" export EDGIO_ENVIRONMENT_ID="Your Edgio Environment ID" # If have more than one Environment ID # export EDGIO_ENVIRONMENT_ID="ENVIRONMENT_ID_1 ENVIRONMENT_ID_2" acme.sh --deploy -d example.com --deploy-hook edgio ``` ## 31. Deploy your cert to Netlify You must define the ACCESS TOKEN, SITE ID before getting started. To create a Personal access tokens ([Documentation](https://app.netlify.com/user/applications#personal-access-tokens)). To get the Site ID, navigate to the SITE where the certificate is to be deployed. Once there, you can find the Site ID within the 'Site configuration'. ```sh export Netlify_ACCESS_TOKEN="Your Netlify Access Token" export Netlify_SITE_ID="Your Netlify Site ID" # If have more than one SITE ID # export Netlify_SITE_ID="SITE_ID_1 SITE_ID_2" acme.sh --deploy -d example.com --deploy-hook netlify ``` ## 32. Deploy your cert to DirectAdmin You must define the following variables before getting started. **export DirectAdmin_SCHEME**: Optional, https or http, defaults to https.\ **DirectAdmin_ENDPOINT**: The hostname and port of DirectAdmin Panel.\ **DirectAdmin_USERNAME**: DirectAdmin username\ **DirectAdmin_KEY**: DirectAdmin Login Key or Password\ **DirectAdmin_MAIN_DOMAIN**: Domain names for which the certificate need to be deployed. Get it in 'Domain Management' page. You can use the Login Key instead of the password ([Documentation](https://docs.directadmin.com/directadmin/customizing-workflow/api-all-about.html#creating-a-login-key)). Allow `CMD_SSL`, `CMD_API_SSL` command privileges. ```sh export DirectAdmin_SCHEME="https" export DirectAdmin_ENDPOINT="example.com:2222" export DirectAdmin_USERNAME="Your DirectAdmin Username" export DirectAdmin_KEY="Your DirectAdmin Login Key or Password" export DirectAdmin_MAIN_DOMAIN="Your DirectAdmin Main Domain, NOT Subdomain" acme.sh --deploy -d example.com --deploy-hook directadmin ``` ## 33. Deploy your cert to KeyHelp You must define the following variables before getting started. **DEPLOY_KEYHELP_BASEURL**: The protocol and hostname of KeyHelp Panel, no "/" at the end.\ **DEPLOY_KEYHELP_USERNAME**: Your Username of KeyHelp Panel.\ **DEPLOY_KEYHELP_PASSWORD**: Your Password of KeyHelp Panel .\ **DEPLOY_KEYHELP_DOMAIN_ID**: Open the 'Edit domain' page, and you will see id=xxx at the end of the URL. This is the Domain ID.\ **DEPLOY_KEYHELP_ENFORCE_HTTPS**: Input 0 or 1, input 1 to enable Enforce HTTP to HTTPS redirection. ```sh export DEPLOY_KEYHELP_BASEURL="https://keyhelp.example.com" export DEPLOY_KEYHELP_USERNAME="Your KeyHelp Username" export DEPLOY_KEYHELP_PASSWORD="Your KeyHelp Password" export DEPLOY_KEYHELP_DOMAIN_ID="Depoly certificate to this Domain ID" export DEPLOY_KEYHELP_ENFORCE_HTTPS="1" # If have more than one domain name # export DEPLOY_KEYHELP_DOMAIN_ID="DOMAIN_ID_1 DOMAIN_ID_2 DOMAIN_ID_3" acme.sh --deploy -d example.com --deploy-hook keyhelp ``` ## 34. Deploy your certificate to CDN or DCDN of Alibaba Cloud (Aliyun) 使用 acme.sh 部署到阿里云 CDN / DCDN 之前，需要先创建[访问密钥](https://help.aliyun.com/zh/ram/user-guide/create-an-accesskey-pair)，并赋予相应权限： [CDN](https://help.aliyun.com/zh/cdn/developer-reference/api-cdn-2018-05-10-setcdndomainsslcertificate#api-detail-31) / [DCDN](https://help.aliyun.com/zh/dcdn/developer-reference/api-dcdn-2018-01-15-setdcdndomainsslcertificate#api-detail-31)。 ```sh $ export Ali_Key="foo" $ export Ali_Secret="bar" ``` 该访问密钥，与 acme.sh 中的其它阿里云服务共享（例如 DNS API 中的 `dns_ali` 功能）。如果已经在其它地方设置过 `Ali_Key` 和 `Ali_Secret` 变量，会自动复用。 > [!TIP] > **本文档以 CDN 为例，DCDN 用户需要修改变量名中的 `CDN` 为 `DCDN`，并将 deploy-hook 从 `ali_cdn` 换成 `ali_dcdn` 。** 完成准备工作之后，您就可以通过下面的命令开始部署 SSL 证书到阿里云 CDN ： ```sh $ acme.sh --deploy -d example.com --deploy-hook ali_cdn ``` 假如您使用多域名或泛域名证书，您可能需要设置 `DEPLOY_ALI_CDN_DOMAIN` 或 ``DEPLOY_ALI_DCDN_DOMAIN` 变量，指定想要部署的域名（请注意泛域名前面的点）： ```sh $ export DEPLOY_ALI_CDN_DOMAIN=".example.com" $ acme.sh --deploy -d example.com --deploy-hook ali_cdn ``` 假如需要部署多个域名, 使用空格将域名分隔开来: ```sh $ export DEPLOY_ALI_CDN_DOMAIN="cdn1.example.com cdn2.example.com" $ acme.sh --deploy -d example.com --deploy-hook ali_cdn ``` ### English version You should [create an AccessKey pair](https://www.alibabacloud.com/help/en/ram/user-guide/create-an-accesskey-pair) and set the proper permissions for [CDN](https://www.alibabacloud.com/help/en/cdn/developer-reference/api-cdn-2018-05-10-setcdndomainsslcertificate#api-detail-31) or [DCDN](https://www.alibabacloud.com/help/en/dcdn/developer-reference/api-dcdn-2018-01-15-setdcdndomainsslcertificate#api-detail-31) before deploying your certificate. ```sh $ export Ali_Key="foo" $ export Ali_Secret="bar" ``` Notice that, this access key pair will be shared with other Alibaba Cloud features in acme.sh (eg. `dns_ali` in DNS API). > [!TIP] > **This document uses CDN as a reference. For DCDN users, it is necessary to modify the variable names by replacing `CDN` with `DCDN`, and use the `ali_dcdn` deploy-hook instead of ali_cdn.** After having the preparation, you can deploy certificate by following command: ```sh $ acme.sh --deploy -d example.com --deploy-hook ali_cdn ``` (Optional), If you are using a certificate with multiple domains or wildcard domains, you may need to export `DEPLOY_ALI_CDN_DOMAIN` to specify the domain to update (please note the leading dot for wildcard domains): ```sh $ export DEPLOY_ALI_CDN_DOMAIN=".example.com" $ acme.sh --deploy -d example.com --deploy-hook ali_cdn ``` If you want to deploy more than one domain, just use space to split them: ```sh $ export DEPLOY_ALI_CDN_DOMAIN="cdn1.example.com cdn2.example.com" $ acme.sh --deploy -d example.com --deploy-hook ali_cdn ``` ## 35. Deploy your certificate to Ruckus Unleashed or Ruckus ZoneDirector For your first deployment, you must specify your Unleashed administrative credentials. If you are using a SAN or wildcard certificate, then you must also specify a hostname. Unleashed devices ship with a self-signed certificate, so you need to add the --insecure option to the initial deploy command. ```sh export RUCKUS_USER= export RUCKUS_PASS= export RUCKUS_HOST="unleashed.example.com" acme.sh --insecure --deploy -d example.com --deploy-hook ruckus ``` After your first deployment, the environment variables aren't needed (they're stored by acme.sh). The --insecure option is also unnecessary once a valid certificate has been deployed. ```sh acme.sh --deploy -d example.com --deploy-hook ruckus ``` **Notes** ECDSA certificates aren't supported by current Unleashed releases. You must deploy an RSA certificate. Deploying a certificate will reboot your Unleashed device(s), after which the new certificate will be used. Be aware that older Unleashed APs may take 10 minutes to reboot completely. The Unleashed controller software runs on the elected Master AP. If you have multiple APs then ensure the management interface doesn't migrate to a different IP address by configuring either a Preferred Master AP or a Management Interface. Although these notes only mention Unleashed, the deploy hook also supports Ruckus ZoneDirector. ## 36. Deploying to multiple services with the same hooks Multideploy allows you to deploy your certificates to multiple services, even those that use the same hook. To use this hook, issue a cert and create a new file, `multideploy.yml,` in the certificate directory. This must contain a version and the services to which your certificate will be deployed. All services specified will be used to deploy your certificate! ### Compatibility | **acme.sh version** | **multideploy version** | **Pull request status** | |---------------------|-------------------------|------------------------ | | <= 3.1.0 | not supported | | | dev | 1.0 | ![GitHub issue/pull request detail](https://img.shields.io/github/pulls/detail/state/acmesh-official/acme.sh/6241?style=flat-square&label=Pending%20changes) |
Version 1.0 * Basic configuration of services and configurations. * Allows multiple configurations that can contain multiple services. ```yaml version: 1.0 services: - name: "YOUR_SERVICE" hook: "YOUR_HOOK" environment: - ENV_TO_EXPORT: "YOUR_CONTENT" ```
### Example `multideploy.yaml` for three docker containers: ```yaml # check your acme.sh version in wiki! version: 1.0 services: - name: "traefik" hook: "docker" environment: - DEPLOY_DOCKER_CONTAINER_LABEL: "sh.acme.autoload.service=traefik" - DEPLOY_DOCKER_CONTAINER_KEY_FILE: "/certs/$DOMAIN_DIR/key.pem", - DEPLOY_DOCKER_CONTAINER_CERT_FILE: "/certs/$DOMAIN_DIR/cert.pem", - DEPLOY_DOCKER_CONTAINER_CA_FILE: "/certs/$DOMAIN_DIR/ca.pem", - DEPLOY_DOCKER_CONTAINER_FULLCHAIN_FILE: "/certs/$DOMAIN_DIR/fullchain.pem" - name: "adguardhome" hook: "docker" environment: - DEPLOY_DOCKER_CONTAINER_LABEL: "sh.acme.autoload.service=dns01" - DEPLOY_DOCKER_CONTAINER_KEY_FILE: "/opt/adguardhome/work/data/encryption/$DOMAIN_DIR/key.pem" - DEPLOY_DOCKER_CONTAINER_FULLCHAIN_FILE: "/opt/adguardhome/work/data/encryption/$DOMAIN_DIR/fullchain.pem" - name: "technitium-dns" hook: "docker" environment: - DEPLOY_DOCKER_CONTAINER_LABEL: "sh.acme.autoload.service=dns02" - DEPLOY_DOCKER_CONTAINER_PFX_FILE: "/etc/dns/certs/$DOMAIN_DIR.pfx" - name: "router01" hook: "routeros" environment: - ROUTER_OS_USERNAME: "certuser" - ROUTER_OS_HOST: "router.example.com" - ROUTER_OS_PORT: "22" - name: "nas01" hook: "synology_dsm" environment: - SYNO_SCHEME: "http" - SYNO_HOSTNAME: "localhost" - SYNO_PORT: "5000" - SYNO_CREATE: "1" - SYNO_CERTIFICATE: "PROD-$_cdomain" ``` `$DOMAIN_DIR` is a provided variable that contains the name of the directory your certificate was created in. You can use this while deploying your certificate to services. This is helpful if you deploy more than one certificate to the same service. If you want to use a filename other than `multideploy.yml`, you can specify it with `MULTIDEPLOY_FILENAME`. ```sh export MULTIDEPLOY_FILENAME="deploy.yaml" acme.sh --deploy -d example.com --deploy-hook multideploy ``` If no filename is exported, the hook will always look for the config `multideploy.yml`! ### Bug reporting / feature request Create a new issue and mention @tomo2403 to get help. Currently, there is no other contributor for this hook.acme.sh-0.0~git20250417.7502af3/dnsapi.md000066400000000000000000002076551500024665000172210ustar00rootroot00000000000000# How to use DNS API If your DNS provider doesn't provide API access, you can use our [DNS alias mode](https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode) * [1. CloudFlare](#dns_cf) * [2. DNSPod.cn Option:](#dns_dp) * [4. Use GoDaddy.com domain API to automatically issue cert](#dns_gd) * [5. Use PowerDNS embedded API to automatically issue cert](#dns_pdns) * [6. Use OVH, Kimsufi, So you Start API to automatically issue cert](#dns_ovh) * [7. Use nsupdate to automatically issue cert](#dns_nsupdate) * [8. Use LuaDNS domain API](#dns_lua) * [9. Use DNSMadeEasy domain API](#dns_me) * [10. Use Amazon Route53 domain API](#dns_aws) * [11. Use Aliyun domain API to automatically issue cert](#dns_ali) * [12. Use ISPConfig 3.1 API](#dns_ispconfig) * [13. Use Alwaysdata domain API](#dns_ad) * [14. Use Linode domain API](#dns_linode_v4) * [15. Use FreeDNS](#dns_freedns) * [16. Use cyon.ch](#dns_cyon) * [18. Use Gandi LiveDNS API](#dns_gandi_livedns) * [19. Use Knot (knsupdate) DNS API to automatically issue cert](#dns_knot) * [20. Use DigitalOcean API (native)](#dns_dgon) * [21. Use ClouDNS.net API](#dns_cloudns) * [22. Use Infoblox API](#dns_infoblox) * [23. Use VSCALE API](#dns_vscale) * [24. Use Dynu API](#dns_dynu) * [25. Use DNSimple API](#dns_dnsimple) * [26. Use NS1.com API](#dns_nsone) * [27. Use DuckDNS.org API](#dns_duckdns) * [28. Use Name.com API](#dns_namecom) * [29. Use Dyn Managed DNS API to automatically issue cert](#dns_dyn) * [30. Use pdd.yandex.ru API](#dns_yandex) * [31. Use Hurricane Electric](#dns_he) * [33. Use INWX](#dns_inwx) * [35. Use Namesilo.com API](#dns_namesilo) * [36. Use autoDNS (InternetX)](#dns_autodns) * [37. Use Azure DNS](#dns_azure) * [38. Use selectel.com(selectel.ru) domain API to automatically issue cert](#dns_selectel) * [39. Use zonomi.com domain API to automatically issue cert](#dns_zonomi) * [40. Use DreamHost DNS API](#dns_dreamhost) * [41. Use DirectAdmin API](#dns_da) * [42. Use KingHost DNS API](#dns_zilore) * [43. Use Zilore DNS API](#dns_zilore) * [44. Use Loopia API](#dns_loopia) * [45. Use ACME DNS API](#dns_acmedns) * [47. Use Euserv.eu API](#dns_euserv) * [48. Use DNSPod.com domain API to automatically issue cert](#dns_dpi) * [49. Use Google Cloud DNS API to automatically issue cert](#dns_gcloud) * [50. Use ConoHa API](#dns_conoha) * [51. Use Netcup API](#dns_netcup) * [53. Use Namecheap](#dns_namecheap) * [54. Use MyDNS.JP API](#dns_mydnsjp) * [55. Use hosting.de API](#dns_hostingde) * [56. Use Neodigit.net API](#dns_neodigit) * [57. Use Exoscale API](#dns_exoscale) * [58. Using PointHQ API to issue certs](#dns_pointhq) * [59. Use Active24 API](#dns_active24) * [60. Use do.de API](#dns_doapi) * [61. Use Nexcess API](#dns_nw) * [62. Use Thermo.io API](#dns_nw) * [63. Use Futurehosting API](#dns_nw) * [65. Use Online API](#dns_online) * [66. Use MyDevil.net](#dns_mydevil) * [67. Use Core-Networks API to automatically issue cert](#dns_cn) * [70. Use UltraDNS API](#dns_ultra) * [71. Use deSEC.io](#dns_desec) * [72. Use OpenProvider API](#dns_openprovider) * [73. Use MaraDNS API](#dns_maradns) * [74. Use Hetzner API](#dns_hetzner) * [75. Use DDNSS.de API](#dns_ddnss) * [76. Use NLnetLabs NSD](#dns_nsd) - [76. Use Schlundtech](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_schlundtech) - [77. Use your one.com credentials as you would login into the control panel.](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_one) - [78. Use AcmeProxy DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_acmeproxy) - [79. Use internetbs.net API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_internetbs) - [80. Use durabledns.com API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_durabledns) - [81. Use reg.ru API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_regru) - [82. Use Vultr DNS API to automatically issue cert](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_vultr) - [83. Use jdcloud.com DNS API to automatically issue cert](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_jd) - [84. Use hexonet.com DNS API to automatically issue a cert](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_hexonet) - [85. Use Domeneshop DNS API to automatically issue a cert](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_domeneshop) - [86. Use OPNsense embedded API to automatically issue cert](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_opnsense) - [87. Use the RcodeZero API to automatically issue cert](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_rcode0) - [88. Use MailinaBox](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_miab) - [89. Use nic.ru DNS](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_nic) - [90. Use Leaseweb.com domain API to automatically issue cert](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_leaseweb) - [91. Use variomedia.de domain API to automatically issue cert](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_variomedia) - [92. Use Plesk XML API to automatically issue cert](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_pleskxml) - [93. Use PDNS Manager API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_pdnsmanager) - [94. Use Misaka.io domain API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_misaka) - [95. Use easyDNS.net API to automatically issue a cert](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_easydns) - [96. Use CloudDNS API to automatically issue a cert](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_clouddns) - [97. Use dynv6 API to automatically issue a cert](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_dynv6) - [98. Use All-Inkl.com domain API to automatically issue cert](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_kas) - [99. Use Constellix domain API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_constellix) - [100. Use Namemaster domain API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_nm) - [101. Use HostingUkraine domain API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_hostingukraine) - [102. Use ArvanCloud domain API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_arvan) - [103. Use Joker.com domain API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_joker) - [104. Use 1984Hosting domain API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_1984hosting) - [105. Use Aruba domain API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_aruba) - [106. Use TransIP domain API:](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_transip) - [107. Use dyndnsfree.de API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_df) - [108. Use Njalla API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_njalla) - [109. Use Vercel API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_vercel) - [110. Use Hetzner DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_hetzner) - [111. Use kapper.net DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_kappernet) - [112. Use Wedos API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_wedos) - [113. Use Shellrent API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_shellrent) - [114. Use OpenStack domain API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_openstack) - [115. Use Netlify API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_netlify) - [116. Use Akamai Edge DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_edgedns) - [117. Use WEDOS DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_wedos) - [118. Use Websupport DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_websupport) - [119. Use infomaniak.com API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_infomaniak) - [120. Use bookmyname.com API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_bookmyname) - [121. Use anexia.com CloudDNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_anx) - [122. Use Synology DSM Synology DNS Server API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_synology_dsm) - [123. Use HuaweiCloud API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_huaweicloud) - [124. Use Simply.com API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_simply) - [125. Use World4You API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_world4you) - [126. Use Scaleway API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_scaleway) - [128. Use RackCorp API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_rackcorp) - [129. Using the IONOS domain API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_ionos) - [130. Using the Porkbun API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_porkbun) - [131. Using the Aurora API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_aurora) - [132. Using the Azion DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_azion) - [133. Using Oracle Cloud Infrastructure DNS](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_oci) - [134. Utilisation de l'API DNS Hostline Hébergement VPS](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_hostline) - [135. Use Veesp domain API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_veesp) - [136. Use cPanel DNS systems](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_cpanel) - [137. Use ISPMan domain API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_ispman) - [138. Use dnsHome.de DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_dnshome) - [139. Use mythic-beasts.com DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_mythic_beasts) - [140. Use s-dns.de API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_sdns) - [141. Using the united-domains reselling DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_udr) - [142. Using the curanet DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_curanet) - [143. Use ArtFiles.de DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_artfiles) - [144. Use Geoscaling.com DNS2](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_geoscaling) - [145. Use fornex.com API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_fornex) - [146. Use DNS.Services API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_dnsservices) - [147. Use Nodion DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_nodion) - [148. Use dns.la API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_la) - [149. Use Yandex Cloud DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_yc) - [150. Use Bunny DNS API to automatically issue cert](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_bunny) - [151. Use Selfhost DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_selfhost) - [152. Use rage4 DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_rage4) - [153. Use GCore DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_gcore) - [154. Use dynadot DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_dynadot) - [155. Use IPv64 DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_ipv64) - [156. Use Nanelo DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_nanelo) - [157. Use Google Domains DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_googledomains) - [158. Use DNSExit API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_dnsexit) - [159. Use Lima-City API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_limacity) - [160. Use TencentCloud (DNSPod) API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_tencent) - [161. Use Samba AD DC API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_samba) - [162. Use West.cn API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_west_cn) - [163. Use Hosttech API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_hosttech) - [164. Use Alviy.com DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_alviy) - [165. Use Timeweb Cloud DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_timeweb) - [166. Use myLoc.de / webtropia.com DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_myloc) - [167. Use Yandex 360 for Business DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_yandex360) - [168. Use HE DDNS DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_he_ddns) - [169. Using the IONOS Cloud DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_ionos_cloud) - [170. Using the Omg.lol DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_omglol) - [171. Use Power-Mailinabox](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_pmiab) - [172. Use Technitium DNS Server API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_technitium) - [173. Use ZoneEdit DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_zoneedit) - [174. Use Anikeen Cloud DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_anikeen) - [175. Use mijn.host DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_mijnhost) - [176. Use OpenProvider (REST) DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_openprovider_rest) - [177. Use Beget.com DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_beget) - [Use custom API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_myapi) - [Use lexicon DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_lexicon) ## 1. CloudFlare Option: Cloudflare Domain API offers two methods to automatically issue certs: (a) creating a restrictive API token with specific permissions; or (b) using the global API key associated with your Cloudflare account, which has all permissions. Using method (b) is strongly NOT recommended as leakage of the global API token will completely compromise your account, though the key can be reset if this occurs. By contrast, method (a) is recommended because if a restrictive API token is leaked, the attack surface is small, it can simply be deleted/revoked, and its permissions can also be changed at any time via your Cloudflare profile settings. ### (a) Using a restrictive API token You will need to create an API token which either: (i) has permissions to edit a single specific DNS zone; or (ii) has permissions to edit multiple DNS zones. You can do this via your Cloudflare profile page, under the [API Tokens section](https://dash.cloudflare.com/profile/api-tokens). When your create the token, under Permissions, select Zone > DNS > Edit, and under Zone Resources, only include the specific DNS zones within which you need to perform ACME DNS challenges. The API token is a 40-character string that may contain uppercase letters, lowercase letters, numbers, and underscores. You must provide it to acme.sh by setting the environment variable `CF_Token` to its value, e.g. run `export CF_Token="Y_jpG9AnfQmuX5Ss9M_qaNab6SQwme3HWXNDzRWs"`. #### (i) Single DNS zone You must give acme.sh the *zone ID* of the DNS zone it needs to edit. This is a 32-character hexadecimal string (e.g. `763eac4f1bcebd8b5c95e9fc50d010b4`), and should not be confused with the *zone name* (e.g. `example.com`). This zone ID can be found via the Cloudflare dashboard, on the zone's Overview page, in the right-hand sidebar. You provide this info by setting the environment variable `CF_Zone_ID` to this zone ID, e.g. run `export CF_Zone_ID="763eac4f1bcebd8b5c95e9fc50d010b4"`. #### (ii) Multiple DNS zones You must give acme.sh the *account ID* of the Cloudflare account to which the relevant DNS zones belong. This is a 32-character hexadecimal string, and should not be confused with other account identifiers, such as the account email address (e.g. `alice@example.com`) or global API key (which is also a 32-character hexadecimal string). This account ID can be found via the Cloudflare dashboard, as the end of the URL when logged in, or on the Overview page of any of your zones, in the right-hand sidebar, beneath the zone ID. You provide this info by setting the environment variable `CF_Account_ID` to this account ID, e.g. run `export CF_Account_ID="763eac4f1bcebd8b5c95e9fc50d010b4"`. ### (b) Using the global API key You can get your global API key from your Cloudflare profile page, under the [API tokens section](https://dash.cloudflare.com/profile/api-tokens). Click "View" next to Global API key, verify your Cloudflare password, and it will be revealed to you. It is a 32-character hexadecimal string that you must provide to acme.sh by setting the environment variable `CF_Key` to its value. You must also set `CF_Email` to the email address that is associated with your Cloudflare account; this is the email address you enter when logging in to Cloudflare. For example: ```sh export CF_Key="763eac4f1bcebd8b5c95e9fc50d010b4" export CF_Email="alice@example.com" ``` ### Getting a certificate Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_cf -d example.com -d '*.example.com' ``` Any environment variables that were set and used when issuing the certificate will be saved in `~/.acme.sh/account.conf` so that they can be automatically reused in future when issuing new certificates or renewing existing certificates using `dns_cf`. ## 2. DNSPod.cn Option: The DNSPod.cn Domain API option requires that you first login to your account to get a DNSPod API Key and ID. > The DNSPod API Key refers to the `DNSPod Token` found under `API Keys` in my account settings on the https://dnspod.cn. ```sh export DP_Id= export DP_Key= ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_dp -d example.com -d *.example.com ``` The `DP_Id` and `DP_Key` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 3. CloudXNS.com ~~Removed~~ ## 4. Use GoDaddy.com domain API to automatically issue cert Only possible if you have more than 10 domains or a Discount Domain Club subscription! See [Reddit](https://www.reddit.com/r/godaddy/comments/1chs1j8/godaddy_access_denied_via_apicall/) First you need to login to your GoDaddy account to get your API Key and Secret. https://developer.godaddy.com/keys/ Please create a Production key, instead of a Test key. ```sh export GD_Key="" export GD_Secret="" ``` Ok, let's issue a cert now. For GoDaddy, it is recommended that you specify a 600 second dnssleep. ```sh ./acme.sh --issue --dns dns_gd --dnssleep 600 -d example.com -d *.example.com ``` The `GD_Key` and `GD_Secret` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 5. Use PowerDNS embedded API to automatically issue cert First you need to login to your PowerDNS account to enable the API and set your API-Token in the configuration. https://doc.powerdns.com/md/httpapi/README/ ```sh export PDNS_Url="http://ns.example.com:8081" export PDNS_ServerId="localhost" export PDNS_Token="0123456789ABCDEF" export PDNS_Ttl=60 ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_pdns -d example.com -d *.example.com ``` The `PDNS_Url`, `PDNS_ServerId`, `PDNS_Token` and `PDNS_Ttl` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 6. Use OVH, Kimsufi, So you Start API to automatically issue cert See [How to use OVH domain API](https://github.com/acmesh-official/acme.sh/wiki/How-to-use-OVH-domain-api) ## 7. Use nsupdate to automatically issue cert ncupdate is [RFC 2136 Dynamic DNS Update](https://datatracker.ietf.org/doc/html/rfc2136.html) client. [Man page](https://bind9.readthedocs.io/en/v9.18.19/manpages.html#nsupdate-dynamic-dns-update-utility) First, generate a key for updating the zone ```sh b=$(dnssec-keygen -a hmac-sha512 -b 512 -n USER -K /tmp foo) cat > /etc/named/keys/update.key < ## 8. Use LuaDNS domain API Get your API token at https://api.luadns.com/settings ```sh export LUA_Key="" export LUA_Email="youremail@example.com" ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_lua -d example.com -d *.example.com ``` The `LUA_Key` and `LUA_Email` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 9. Use DNSMadeEasy domain API Get your API credentials at https://cp.dnsmadeeasy.com/account/info ```sh export ME_Key="" export ME_Secret="" ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_me -d example.com -d *.example.com ``` The `ME_Key` and `ME_Secret` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 10. Use Amazon Route53 domain API See [How to use Amazon Route53 API](https://github.com/acmesh-official/acme.sh/wiki/How-to-use-Amazon-Route53-API) ```sh export AWS_ACCESS_KEY_ID="" export AWS_SECRET_ACCESS_KEY="" ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_aws -d example.com -d *.example.com ``` If you get an `AWS Route53 rate exceeded` error, you can add a sleep time between api requests: ```sh export AWS_DNS_SLOWRATE=1 (sleep between API requests in seconds) ``` The `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` and `AWS_DNS_SLOWRATE` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. The `AWS_DNS_SLOWRATE` will enable the sleep between API requests to AWS servers. It will help to mitigate the AWS rate limit ## 11. Use Aliyun domain API to automatically issue cert First you need to login to your Aliyun account to get your RAM API key. [https://ram.console.aliyun.com/users](https://ram.console.aliyun.com/users) ```sh export Ali_Key="" export Ali_Secret="" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_ali -d example.com -d *.example.com ``` The `Ali_Key` and `Ali_Secret` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 12. Use ISPConfig 3.1 API This only works for ISPConfig 3.1 (and newer). Create a Remote User in the ISPConfig Control Panel. The Remote User must have access to at least `DNS zone functions`, `DNS txt functions` and `Client functions`. ```sh export ISPC_User="xxx" export ISPC_Password="xxx" export ISPC_Api="https://ispc.domain.tld:8080/remote/json.php" export ISPC_Api_Insecure=1 ``` If you have installed ISPConfig on a different port, then alter the 8080 accordingly. Leave ISPC_Api_Insecure set to 1 if you have no valid ssl cert for your installation. Change it to 0 if you have a valid ssl cert. To issue a cert: ```sh ./acme.sh --issue --dns dns_ispconfig -d example.com -d *.example.com ``` The `ISPC_User`, `ISPC_Password`, `ISPC_Api`and `ISPC_Api_Insecure` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 13. Use Alwaysdata domain API First you need to login to your Alwaysdata account to get your API Key. ```sh export AD_API_KEY="" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_ad -d example.com -d *.example.com ``` The `AD_API_KEY` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 14. Use Linode domain API ### Cloud Manager ### Cloud Manager: https://cloud.linode.com/profile/tokens First you need to login to your Linode account to get your API Key. 1. Click on "Add a Personal Access Token". 2. Give the new key a "Label" (we recommend *ACME*) 3. Give it Read/Write access to "Domains" 4. "Submit" and copy the new key into the `LINODE_V4_API_KEY` command below. ```sh export LINODE_V4_API_KEY="..." ``` Due to the reload time of any changes in the DNS records, we have to use the `dnssleep` option to wait at least 15 minutes for the changes to take effect. Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_linode_v4 -d example.com -d *.example.com --dnssleep 900 ``` The `LINODE_V4_API_KEY` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 15. Use FreeDNS [FreeDNS](https://freedns.afraid.org/) does not provide an API to update DNS records (other than IPv4 and IPv6 dynamic DNS addresses). The acme.sh plugin therefore retrieves and updates domain TXT records by logging into the FreeDNS website to read the HTML and posting updates as HTTP. The plugin needs to know your userid and password for the FreeDNS website. ```sh export FREEDNS_User="..." export FREEDNS_Password="..." ``` You need only provide this the first time you run the acme.sh client with FreeDNS validation and then again whenever you change your password at the FreeDNS site. The acme.sh FreeDNS plugin does not store your userid or password but rather saves an authentication token returned by FreeDNS in `~/.acme.sh/account.conf` and reuses that when needed. Now you can issue a certificate. ```sh ./acme.sh --issue --dns dns_freedns -d example.com -d *.example.com ``` Note that you cannot use acme.sh automatic DNS validation for FreeDNS public domains or for a subdomain that you create under a FreeDNS public domain. You must own the top level domain in order to automatically validate with acme.sh at FreeDNS. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2305) ## 16. Use cyon.ch You only need to set your cyon.ch login credentials. If you also have 2 Factor Authentication (OTP) enabled, you need to set your secret token too and have `oathtool` installed. ```sh export CY_Username="your_cyon_username" export CY_Password="your_cyon_password" export CY_OTP_Secret="your_otp_secret" # Only required if using 2FA ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_cyon -d example.com -d *.example.com ``` The `CY_Username`, `CY_Password` and `CY_OTP_Secret` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 17. Use Domain-Offensive/Resellerinterface/Domainrobot API ~~Removed~~ See [60. Use do.de API](#dns_doapi) instead ## 18. Use Gandi LiveDNS API You must enable the new Gandi LiveDNS API first and then create your Personal Access Token (PAT) or api key (deprecated), See: https://api.gandi.net/docs/livedns/ and https://docs.gandi.net/en/managing_an_organization/organizations/personal_access_token.html ```sh export GANDI_LIVEDNS_TOKEN="" ``` or (deprecated): ```sh export GANDI_LIVEDNS_KEY="" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_gandi_livedns -d example.com -d *.example.com ``` ## 19. Use Knot (knsupdate) DNS API to automatically issue cert First, generate a TSIG key for updating the zone. ```sh keymgr tsig generate -t acme_key hmac-sha512 > /etc/knot/acme.key ``` Include this key in your knot configuration file. ```sh include: /etc/knot/acme.key ``` Next, configure your zone to allow dynamic updates. Dynamic updates for the zone are allowed via proper ACL rule with the `update` action. For in-depth instructions, please see [Knot DNS's documentation](https://www.knot-dns.cz/documentation/). ```sh acl: - id: acme_acl address: 192.168.1.0/24 key: acme_key action: update zone: - domain: example.com file: example.com.zone acl: acme_acl ``` Finally, make the DNS server and TSIG Key available to `acme.sh` ```sh export KNOT_SERVER='dns.example.com' export KNOT_KEY='/etc/knot/acme.key' ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_knot -d example.com -d *.example.com ``` The `KNOT_SERVER` and `KNOT_KEY` settings will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 20. Use DigitalOcean API (native) You need to obtain a read and write capable API key from your DigitalOcean account. See: https://www.digitalocean.com/help/api/ ```sh export DO_API_KEY="" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_dgon -d example.com -d *.example.com ``` ## 21. Use ClouDNS.net API You need to set the HTTP API user ID and password credentials. See: https://www.cloudns.net/wiki/article/42/. For security reasons, it's recommended to use a sub user ID that only has access to the necessary zones, as a regular API user has access to your entire account. ```sh # Use this for a sub auth ID export CLOUDNS_SUB_AUTH_ID="" # Use this for a regular auth ID #export CLOUDNS_AUTH_ID="Auth ID" export CLOUDNS_AUTH_PASSWORD="" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_cloudns -d example.com -d *.example.com ``` The `CLOUDNS_AUTH_ID` and `CLOUDNS_AUTH_PASSWORD` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 22. Use Infoblox API First you need to create/obtain API credentials on your Infoblox appliance. ```sh export Infoblox_Creds="username:password" export Infoblox_Server="ip or fqdn of infoblox appliance" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_infoblox -d example.com -d *.example.com ``` Note: This script will automatically create and delete the ephemeral txt record. The `Infoblox_Creds` and `Infoblox_Server` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 23. Use VSCALE API First you need to create/obtain API tokens on your [settings panel](https://vscale.io/panel/settings/tokens/). ```sh export VSCALE_API_KEY="" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_vscale -d example.com -d *.example.com ``` ## 24. Use Dynu API First you need to create/obtain API credentials from your Dynu account. See: https://www.dynu.com/resources/api/documentation ```sh export Dynu_ClientId="" export Dynu_Secret="" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_dynu -d example.com -d *.example.com ``` The `Dynu_ClientId` and `Dynu_Secret` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 25. Use DNSimple API First you need to login to your [DNSimple.com](https://dnsimple.com) account and generate a new oauth token. `https://dnsimple.com/a/{your account id}/account/automation` **Note:** This is an _account_ token and not a user token. The account token is needed to infer the `account_id` used in requests. A user token will not be able to determine the correct account to use. You may check tokens at https://dnsimple.com/a//account/access_tokens ```sh export DNSimple_OAUTH_TOKEN="" ``` To issue the cert just specify the `dns_dnsimple` API. ```sh ./acme.sh --issue --dns dns_dnsimple -d example.com -d *.example.com ``` The `DNSimple_OAUTH_TOKEN` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/pho3nixf1re/acme.sh/issues) ## 26. Use NS1.com API ```sh export NS1_Key="" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_nsone -d example.com -d *.example.com ``` ## 27. Use DuckDNS.org API [DuckDNS.org](https://www.duckdns.org/) is a popular free DDNS provider. You can get your own subdomain like `mydomain.duckdns.org`. To configure it visit the DuckDNS and get your API token: ```sh export DuckDNS_Token="" ``` Ok, let's issue a cert now: ``` acme.sh --issue --dns dns_duckdns -d mydomain.duckdns.org ``` ## 28. Use Name.com API Create your API token here: https://www.name.com/account/settings/api Note: `Namecom_Username` should be your Name.com username and not the token name. If you accidentally run the script with the token name as the username see `~/.acme.sh/account.conf` to fix the issue ```sh export Namecom_Username="" export Namecom_Token="" ``` And now you can issue certs with: ```sh ./acme.sh --issue --dns dns_namecom -d example.com -d *.example.com ``` If you had Two-step Authentication enabled, make sure to change your security setting, read this guide for help: [Using API with Two-step Authentication](https://www.name.com/support/articles/360007989433-Using-API-with-Two-step-Authentication) Report any bugs or issues [here](https://github.com/raidenii/acme.sh/issues) ## 29. Use Dyn Managed DNS API to automatically issue cert First, login to your Dyn Managed DNS account: https://portal.dynect.net/login/ It is recommended to add a new user specific for API access. The minimum "Zones & Records Permissions" required are: ``` RecordAdd RecordUpdate RecordDelete RecordGet ZoneGet ZoneAddNode ZoneRemoveNode ZonePublish ``` Pass the API user credentials to the environment: ```sh export DYN_Customer="" export DYN_Username="" export DYN_Password="" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_dyn -d example.com -d *.example.com ``` The `DYN_Customer`, `DYN_Username` and `DYN_Password` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 30. Use pdd.yandex.ru API [The Yandex DNS API is no longer supported.](https://github.com/acmesh-official/acme.sh/issues/4555) pdd.yandex.ru API was discontinued and superseded by the Yandex 360 for Business DNS API. [How to use the Yandex 360 for Business DNS API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_yandex360) ## 31. Use Hurricane Electric [Hurricane Electric he.net](https://dns.he.net/) doesn't have an API so just set your login credentials like so: ```sh export HE_Username="" export HE_Password="" ``` Then you can issue your certificate: ```sh ./acme.sh --issue --dns dns_he -d example.com -d *.example.com ``` The `HE_Username` and `HE_Password` settings will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/angel333/acme.sh) or to . ## 32. Use UnoEuro API to automatically issue cert **UPD** The UnoEuro is now [Simply.com](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_simply) ## 33. Use INWX [INWX.de](https://www.inwx.de/) offers a [xmlrpc api](https://www.inwx.de/de/help/apidoc) with your standard login credentials, set them like so: ```sh export INWX_User="" export INWX_Password="" ``` Then you can issue your certificates with: ```sh ./acme.sh --issue --dns dns_inwx -d example.com -d *.example.com ``` The `INWX_User` and `INWX_Password` settings will be saved in `~/.acme.sh/account.conf` and will be reused when needed. If your account is secured by mobile tan you have also defined the shared secret. ```sh export INWX_Shared_Secret="" ``` You may need to re-enable the mobile tan to gain the shared secret. ## 34. User Servercow API v1 Create a new user from the Servercow control center. Don't forget to activate **DNS API** for this user. ```sh export SERVERCOW_API_Username="" export SERVERCOW_API_Password="" ``` Now you cann issue a cert: ```sh ./acme.sh --issue --dns dns_servercow -d example.com -d *.example.com ``` Both, `SERVERCOW_API_Username` and `SERVERCOW_API_Password` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 35. Use Namesilo.com API You'll need to generate an API key at https://www.namesilo.com/account/api-manager Optionally you may restrict the access to an IP range there. ```sh export Namesilo_Key="" ``` And now you can issue certs with: ```sh ./acme.sh --issue --dns dns_namesilo -d example.com -d *.example.com --dnssleep 900 ``` ## 36. Use autoDNS (InternetX) [InternetX](https://www.internetx.com/) offers a [xml api](https://help.internetx.com/display/API/AutoDNS+XML-API) with your standard login credentials, set them like so: ```sh export AUTODNS_USER="yourusername" export AUTODNS_PASSWORD="password" export AUTODNS_CONTEXT="context" ``` Then you can issue your certificates with: ```sh ./acme.sh --issue --dns dns_autodns -d example.com -d *.example.com ``` The `AUTODNS_USER`, `AUTODNS_PASSWORD` and `AUTODNS_CONTEXT` settings will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 37. Use Azure DNS You have three options with Azure DNS: 1. Create and use a Service Principal with client secrets (recommended) 2. Using a Managed Identity (has to run on a resource in Azure) 3. Use a provided Bearer token (advanced scenarios only, the Bearer token has a limited lifetime) ### Use Service Principal You have to create a service principal first. See: [How to use Azure DNS](https://github.com/acmesh-official/acme.sh/wiki/How-to-use-Azure-DNS) ```sh export AZUREDNS_SUBSCRIPTIONID="" export AZUREDNS_TENANTID="" export AZUREDNS_APPID="" export AZUREDNS_CLIENTSECRET="" ``` Then you can issue your certificates with: ```sh ./acme.sh --issue --dns dns_azure -d example.com -d *.example.com ``` `AZUREDNS_SUBSCRIPTIONID`, `AZUREDNS_TENANTID`,`AZUREDNS_APPID` and `AZUREDNS_CLIENTSECRET` settings will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ### Use Managed Identity You have to assign a managed identity to your resource, usually a VM, as described [here](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview). This identity requires [DNS Zone Contributor role](https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#dns-zone-contributor). Before running acme.sh following variables need to be set: `export AZUREDNS_SUBSCRIPTIONID="12345678-9abc-def0-1234-567890abcdef"` `export AZUREDNS_MANAGEDIDENTITY=true` Issuing certificates using managed identity clears previously set settings: `AZUREDNS_TENANTID`, `AZUREDNS_APPID`, `AZUREDNS_CLIENTSECRET`. `AZUREDNS_SUBSCRIPTIONID` and `AZUREDNS_MANAGEDIDENTITY` will be saved in ~/.acme.sh/account.conf for future use. Azure App Service and App Functions have an [alternative process](https://learn.microsoft.com/en-us/azure/app-service/overview-managed-identity?tabs=portal%2Chttp#rest-endpoint-reference) to fetch managed identities. When running acme.sh in either, they will use the `IDENTITY_ENDPOINT` and `IDENTITY_HEADER` environment variables that are injected into the service to fetch the managed identity token. ### Use provided Bearer token If you want to use Entra Workload ID in a GitHub Action or similar CI/CD scenarios, you have to use a provided Bearer token. The identity has to have Azure RBAC to be able to add and delete TXT records in the Azure DNS zone. You need to extract the token earlier in your CI/CD, for example with this command: ```sh az account get-access-token --query accessToken --output tsv ``` And then pass it to acme.sh with the environment variable `AZUREDNS_BEARERTOKEN`: ```sh export AZUREDNS_BEARERTOKEN="" ``` Finally, you need to set the tenant ID and subscription ID in the environment variables `AZUREDNS_TENANTID` and `AZUREDNS_SUBSCRIPTIONID`: ```sh export AZUREDNS_SUBSCRIPTIONID="" export AZUREDNS_TENANTID="" ``` Then you can issue the certificate with acme.sh, for example: ```sh ./acme.sh --issue --dns dns_azure -d example.com -d *.example.com ``` ## 38. Use selectel.com(selectel.ru) domain API to automatically issue cert The provider currently supports two API versions: v1 (legacy) and v2 (actual). Legacy version is supported in a limited way and will be disabled from 09.2025. The module supports both API versions. The **SL_Ver** variable is used to determine the API version, the value must be either 'v1' or 'v2'. By default, 'v1'. **_For old installations using the API version 'v1' (legacy), everything remains the same:_** First you need to login to your account to get your API key from: https://my.selectel.ru/profile/apikeys. ```sh export SL_Key="" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_selectel -d example.com -d *.example.com ``` The `SL_Key` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. **_If you are using API version 'v2' (actual), you need to define the following variables:_** ```sh export SL_Ver=v2 # version API export SL_Expire=60 # token lifetime in minutes (0-1440). Default: 1400 minutes export SL_Login_ID= # account number export SL_Project_Name= # project name export SL_Login_Name= # service user name export SL_Pswd= # user password ``` The account number in the control panel can be seen in the upper right corner on the provider's website The service user name can be seen in the control panel: https://my.selectel.ru/iam/users_management/users?type=service The user password can only be viewed when creating a user, or only changed to a new one. Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_selectel -d example.com -d *.example.com ``` ## 39. Use zonomi.com domain API to automatically issue cert First you need to login to your account to find your API key from: http://zonomi.com/app/dns/dyndns.jsp Your will find your api key in the example urls: ```sh https://zonomi.com/app/dns/dyndns.jsp?host=example.com&api_key=1063364558943540954358668888888888 ``` ```sh export ZM_Key="" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_zonomi -d example.com -d *.example.com ``` The `ZM_Key` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 40. Use DreamHost DNS API DNS API keys may be created at https://panel.dreamhost.com/?tree=home.api. Ensure the created key has `add` and `remove` privileges. ```sh export DH_API_KEY="" ./acme.sh --issue --dns dns_dreamhost -d example.com -d *.example.com ``` The `DH_API_KEY` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 41. Use DirectAdmin API The DirectAdmin interface has its own Let's encrypt functionality, but this script can be used to generate certificates for names which are not hosted on DirectAdmin. User must provide login data and URL to the DirectAdmin incl. port. You can create a user which only has access to - CMD_API_DNS_CONTROL - CMD_API_SHOW_DOMAINS By using the Login Keys function. See also https://www.directadmin.com/api.php and https://www.directadmin.com/features.php?id=1298 ```sh export DA_Api="https://remoteUser:remotePassword@da.domain.tld:8443" export DA_Api_Insecure=1 ``` Set `DA_Api_Insecure` to 1 for insecure and 0 for secure -> difference is whether ssl cert is checked for validity (0) or whether it is just accepted (1) Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_da -d example.com -d *.example.com ``` The `DA_Api` and `DA_Api_Insecure` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 42. Use KingHost DNS API API access must be enabled at https://painel.kinghost.com.br/painel.api.php ```sh export KINGHOST_Username="yourusername" export KINGHOST_Password="yourpassword" ./acme.sh --issue --dns dns_kinghost -d example.com -d *.example.com ``` The `KINGHOST_username` and `KINGHOST_Password` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 43. Use Zilore DNS API First, get your API key at https://my.zilore.com/account/api ```sh export Zilore_Key="" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_zilore -d example.com -d *.example.com ``` The `Zilore_Key` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 44. Use Loopia API User must provide login credentials to the Loopia API. The user needs the following permissions: - getDomains - getSubdomains - addSubdomain - removeSubdomain - getZoneRecords - addZoneRecord Set the API endpoint: ```sh export LOOPIA_Api="https://api.loopia./RPCSERV" ``` Depending on your hosting location, `` is one of: `com`, `no`, `rs`, `se`. The default endpoint is `se` TLD. Set the login credentials: ```sh export LOOPIA_User="user@loopiaapi" export LOOPIA_Password="password" ``` And to issue a cert run: ```sh ./acme.sh --issue --dns dns_loopia -d example.com -d *.example.com ``` The exported variables will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 45. Use ACME DNS API ACME DNS is a limited DNS server with RESTful HTTP API to handle ACME DNS challenges easily and securely. https://github.com/joohoi/acme-dns ```sh # Usage: # export ACMEDNS_BASE_URL="https://auth.acme-dns.io" # # You can optionally define an already existing account: # # export ACMEDNS_USERNAME="" # export ACMEDNS_PASSWORD="" # export ACMEDNS_SUBDOMAIN="" ./acme.sh --issue --dns dns_acmedns -d example.com -d *.example.com ``` The credentials will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Note: There's another acme-dns client, whih is not shell only, but supports multi-domain and multiple acme-dns server with a single certificate. If Python is no issue for acme.sh setup, the have a look at https://github.com/maddes-b/acme-dns-client-2 ## 46. Use TELE3 API First you need to login to your TELE3 account to set your API-KEY. https://www.tele3.cz/system-acme-api.html ```sh export TELE3_Key="" export TELE3_Secret="" ./acme.sh --issue --dns dns_tele3 -d example.com -d *.example.com ``` The TELE3_Key and TELE3_Secret will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 47. Use EUserv.eu API First you need to login to your euserv.eu account and activate your API Administration (API Verwaltung). [https://support.euserv.com](https://support.euserv.com) Once you've activated, login to your API Admin Interface and create an API account. Please specify the scope (active groups: domain) and assign the allowed IPs. ```sh export EUSERV_Username="99999.user123" export EUSERV_Password="" ``` Ok, let's issue a cert now: (Be aware to use the `--insecure` flag, because the euserv.eu is still using self-signed certificates!) ```sh ./acme.sh --issue --dns dns_euserv -d example.com -d *.example.com --insecure ``` The `EUSERV_Username` and `EUSERV_Password` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues to ## 48. Use DNSPod.com domain API to automatically issue cert First you need to get your API Key and ID by this [get-the-user-token](https://www.dnspod.com/docs/info.html#get-the-user-token). ```sh export DPI_Id="" export DPI_Key="" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_dpi -d example.com -d *.example.com ``` The `DPI_Id` and `DPI_Key` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 49. Use Google Cloud DNS API to automatically issue cert First you need to authenticate to gcloud. ``` gcloud init ``` **The `dns_gcloud` script uses the active gcloud configuration and credentials.** There is no logic inside `dns_gcloud` to override the project and other settings. If needed, create additional [gcloud configurations](https://cloud.google.com/sdk/gcloud/reference/topic/configurations). You can change the configuration being used without *activating* it; simply set the `CLOUDSDK_ACTIVE_CONFIG_NAME` environment variable. To issue a certificate you can: ```sh export CLOUDSDK_ACTIVE_CONFIG_NAME=default # see the note above ./acme.sh --issue --dns dns_gcloud -d example.com -d *.example.com ``` `dns_gcloud` also supports [DNS alias mode](https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode). ## 50. Use ConoHa API First you need to login to your ConoHa account to get your API credentials. ```sh export CONOHA_Username="xxxxxx" export CONOHA_Password="xxxxxx" export CONOHA_TenantId="xxxxxx" export CONOHA_IdentityServiceApi="https://identity.xxxx.conoha.io/v2.0" ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_conoha -d example.com -d *.example.com ``` The `CONOHA_Username`, `CONOHA_Password`, `CONOHA_TenantId` and `CONOHA_IdentityServiceApi` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 51. Use netcup DNS API to automatically issue cert First you need to login in your CCP account to get your API Key and API Password. ```sh export NC_Apikey="" export NC_Apipw="" export NC_CID="" ``` Now, let's issue a cert: ```sh ./acme.sh --issue --dns dns_netcup -d example.com -d *.example.com ``` The `NC_Apikey`,`NC_Apipw` and `NC_CID` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 52. Use GratisDNS.dk [Removed](https://github.com/acmesh-official/acme.sh/pull/4049) ## 53. Use Namecheap You will need your namecheap username, API KEY (https://www.namecheap.com/support/api/intro.aspx) and your external IP address (or a URL to get it), this IP will need to be whitelisted at Namecheap. Due to Namecheap's API limitation all the records of your domain will be read and re applied, make sure to have a backup of your records you could apply if any issue would arise. ```sh export NAMECHEAP_USERNAME="..." export NAMECHEAP_API_KEY="..." export NAMECHEAP_SOURCEIP="..." ``` The `NAMECHEAP_SOURCEIP` can either be an IP address or a URL to provide it (e.g. https://ifconfig.co/ip). The username and password will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Now you can issue a certificate. ```sh ./acme.sh --issue --dns dns_namecheap -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2107) ## 54. Use MyDNS.JP API First, register to MyDNS.JP and get MasterID and Password. ```sh export MYDNSJP_MasterID="" export MYDNSJP_Password="" ``` To issue a certificate: ```sh ./acme.sh --issue --dns dns_mydnsjp -d example.com -d *.example.com ``` The `MYDNSJP_MasterID` and `MYDNSJP_Password` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 55. Use hosting.de API Create an API key in your hosting.de account here: https://secure.hosting.de The key needs the following rights: - DNS_ZONES_EDIT - DNS_ZONES_LIST Set your API Key and endpoint: ```sh export HOSTINGDE_APIKEY='xxx' export HOSTINGDE_ENDPOINT='https://secure.hosting.de' ``` The plugin can also be used for the http.net API. http.net customers have to set endpoint to https://partner.http.net. Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_hostingde -d example.com -d *.example.com ``` The hosting.de API key and endpoint will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2058) ## 56. Use Neodigit.net API ```sh export NEODIGIT_API_TOKEN="" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_neodigit -d example.com -d *.example.com ``` Neodigit API Token will be saved in `~/.acme.sh/account.conf` and will be used when needed. ## 57. Use Exoscale API Create an API key and secret key in the Exoscale account section Set your API and secret key: ```sh export EXOSCALE_API_KEY='' export EXOSCALE_SECRET_KEY='' ``` Now, let's issue a cert: ```sh ./acme.sh --issue --dns dns_exoscale -d example.com -d *.example.com ``` The `EXOSCALE_API_KEY` and `EXOSCALE_SECRET_KEY` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 58. Using PointHQ API to issue certs Log into [PointHQ account management](https://app.pointhq.com/profile) and copy the API key from the page there. ``` export PointHQ_Key="apikeystringgoeshere" exportPointHQ_Email="accountemail@yourdomain.com" ``` You can then issue certs by using: ``` ./acme.sh --issue --dns dns_pointhq -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2060) ## 59. Use Active24 API Create API credentials in the Active24 Admin [Security and login/API Authentication & Dynamic DNS](https://admin.active24.cz/en/auth/security-settings) Set your API credntials: ```sh export Active24_ApiKey='' export Active24_ApiSecret='' ``` Now, let's issue a cert, set `dnssleep` for propagation new DNS record: ```sh ./acme.sh --issue --dns dns_active24 -d example.com -d *.example.com --dnssleep 120 ``` `120` is usually fine, had success with even lower values like `60` `Active24_ApiKey` and `Active24_ApiSecret` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2059) ## 60. Use do.de API Create an API token in your do.de account ([Create token here](https://www.do.de/account/letsencrypt/) | [Documentation](https://www.do.de/wiki/LetsEncrypt_-_Entwickler)). Set your API token: ```sh export DO_LETOKEN="" ``` To issue a certificate run: ```sh ./acme.sh --issue --dns dns_doapi -d example.com -d *.example.com ``` The API token will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2057) ## 61. Use Nexcess API First, you'll need to login to the [Nexcess.net Client Portal](https://portal.nexcess.net) and [generate a new API token](https://portal.nexcess.net/api-token). Once you have a token, set it in your system's environment: ```sh export NW_API_TOKEN="YOUR_TOKEN_HERE" export NW_API_ENDPOINT="https://portal.nexcess.net" ``` Finally, we'll issue the certificate: (Nexcess DNS publishes at max every 15 minutes, we recommend setting a 900 second `--dnssleep`) ```sh ./acme.sh --issue --dns dns_nw -d example.com -d *.example.com --dnssleep 900 ``` The `NW_API_TOKEN` and `NW_API_ENDPOINT` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2088) ## 62. Use Thermo.io API First, you'll need to login to the [Thermo.io Client Portal](https://core.thermo.io) and [generate a new API token](https://core.thermo.io/api-token). Once you have a token, set it in your system's environment: ```sh export NW_API_TOKEN="YOUR_TOKEN_HERE" export NW_API_ENDPOINT="https://core.thermo.io" ``` Finally, we'll issue the certificate: (Thermo DNS publishes at max every 15 minutes, we recommend setting a 900 second `--dnssleep`) ```sh ./acme.sh --issue --dns dns_nw -d example.com -d *.example.com --dnssleep 900 ``` The `NW_API_TOKEN` and `NW_API_ENDPOINT` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2088) ## 63. Use Futurehosting API First, you'll need to login to the [Futurehosting Client Portal](https://my.futurehosting.com) and [generate a new API token](https://my.futurehosting.com/api-token). Once you have a token, set it in your system's environment: ```sh export NW_API_TOKEN="" export NW_API_ENDPOINT="https://my.futurehosting.com" ``` Finally, we'll issue the certificate: (Futurehosting DNS publishes at max every 15 minutes, we recommend setting a 900 second `--dnssleep`) ```sh ./acme.sh --issue --dns dns_nw -d example.com -d *.example.com --dnssleep 900 ``` The `NW_API_TOKEN` and `NW_API_ENDPOINT` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2088) ## 64. Use Rackspace API Set username and API key, which is available under "My Profile & Settings" ```sh export RACKSPACE_Username="" export RACKSPACE_Apikey="" ``` Now, let's issue a cert: ```sh ./acme.sh --issue --dns dns_rackspace -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2091) ## 65. Use Online API **Note:** the online.net was renamed to scaleway.com and is the same as one.com First, you'll need to retrieve your online.net API key, which is available under https://console.online.net/en/api/access ```sh export ONLINE_API_KEY='' ``` To issue a cert run: ```sh ./acme.sh --issue --dns dns_online -d example.com -d *.example.com ``` `ONLINE_API_KEY` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2093) ## 66. Use MyDevil.net Make sure that you can execute own binaries: ```sh devil binexec on ``` Install acme.sh, or simply `git clone` it into some directory on your MyDevil host account (in which case you should link to it from your `~/bin` directory). If you're not using private IP and depend on default IP provided by host, you may want to edit `crontab` too, and make sure that `acme.sh --cron` is run also after reboot (you can find out how to do that on their wiki pages). To issue a new certificate, run: ```sh ./acme.sh --issue --dns dns_mydevil -d example.com -d *.example.com ``` After certificate is ready, you can install it with [deploy command](https://github.com/acmesh-official/acme.sh/wiki/deployhooks#14-deploy-your-cert-on-mydevilnet). Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2079) ## 67. Use Core-Networks API to automatically issue cert First you need to login to your Core-Networks.de account to set up an API-User. Then export username and password to use these credentials. ```sh export CN_User="" export CN_Password="" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_cn -d example.com -d *.example.com ``` The `CN_User` and `CN_Password` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2142) ## 68. Use NederHost API Create an API token in Mijn NederHost. Set your API key: ```sh export NederHost_Key='xxx' ``` To issue a certificate run: ```sh ./acme.sh --issue --dns dns_nederhost -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2089) ## 69. Use Zone.ee DNS API First, you'll need to retrieve your API key. Estonian instructions https://help.zone.eu/kb/zoneid-api-v2/ ```sh export ZONE_Username=yourusername export ZONE_Key=keygoeshere ``` To issue a cert run: ```sh ./acme.sh --issue --dns dns_zone -d example.com -d *.example.com ``` `ZONE_Username` and `ZONE_Key` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2146) ## 70. Use UltraDNS API UltraDNS is a paid for service that provides DNS, as well as Web and Mail forwarding (as well as reporting, auditing, and advanced tools). More information can be found here: https://www.security.neustar/lp/ultra20/index.html The REST API documentation for this service is found here: https://portal.ultradns.com/static/docs/REST-API_User_Guide.pdf Set your UltraDNS username, and password; these would be the same you would use here: https://portal.ultradns.com/ - or if you create an API only user, that username and password would be better utilized. ```sh export ULTRA_USR="" export ULTRA_PWD="" ``` To issue a cert run: ```sh ./acme.sh --issue --dns dns_ultra -d example.com -d *.example.com ``` `ULTRA_USR` and `ULTRA_PWD` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2118) ## 71. Use deSEC.io Sign up for deSEC.io dynDNS at https://desec.io first. Set your API token (password) by generating one from your account on desec.io. It's also a good idea to restrict the IPv4 / IPv6 address(es) it can be used from. ```sh export DEDYN_TOKEN="" ``` To issue a certificate run: ```sh ./acme.sh --issue --dns dns_desec -d foobar.dedyn.io -d *.foobar.dedyn.io ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2180) ## 72. Use OpenProvider API First, you need to enable API access and retrieve your password hash on https://rcp.openprovider.eu/account/dashboard.php ```sh export OPENPROVIDER_USER="" export OPENPROVIDER_PASSWORDHASH="" ./acme.sh --issue --dns dns_openprovider -d example.com -d *.example.com ``` `OPENPROVIDER_USER` and `OPENPROVIDER_PASSWORDHASH` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2104) ## 73. Use MaraDNS API Make sure you've configured MaraDNS properly and set up a zone file for your domain. See [`csv2(5)`](https://manpages.debian.org/stretch/maradns/csv2.5.en.html). Set the path to your zone file, and path to duende's pid file. See, [`duende(8)`](https://manpages.debian.org/stretch/duende/duende.8.en.html) or `ps -C duende o pid,cmd`). The pid file is used to ask duende to reload the configuration automatically after DNS records are added. ```sh export MARA_ZONE_FILE="/etc/maradns/db.domain.com" export MARA_DUENDE_PID_PATH="/run/maradns/etc_maradns_mararc.pid" ``` Ensure that the acme.sh process has write access to the zone file and read access to the pid file. Issuing a certificate: ```sh ./acme.sh --issue --dns dns_maradns -d example.com -d *.example.com ``` `MARA_ZONE_FILE` and `MARA_DUENDE_PID_PATH` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2072) ## 74. Use Hetzner API Get the API Token: Use [dnsConsole](https://dns.hetzner.com/) to create your hetzner api token. Issuing a certificate (using LetsEncrypt): ```sh export HETZNER_Token="" ./acme.sh --issue --dns dns_hetzner -d example.com -d *.example.com --server letsencrypt ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2943) ## 75. Use DDNSS.de API First create an account at https://ddnss.de. After that create a new host record. In the definition for the host make sure to set the checkbox for "Wildcard" and for "TXT". Note your Api Key (aka "Update Key") displayed at ddnss.de and export in DDNSS_Token variable ```sh export DDNSS_Token="" ``` **Note: Every Cert needs it own Update Key, if you already use the Update Key please generate a new one and export to DDNSS_Token before issue a new Cert. ** After that you can issue a new certificate: ```sh ./acme.sh --issue --dns dns_ddnss -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2230) ## 76. Use NLnetLabs NSD You need to export two variables. Your zonefile which the script will automatically edit: ```sh export Nsd_ZoneFile="/etc/nsd/zones/example.com.zone" ``` And something that calls the nsd-control reload command, either via a script: ```sh export Nsd_Command="/usr/local/bin/sign-and-update.sh example.com" ``` or directly: ```sh export Nsd_Command="sudo nsd-control reload example.com" ``` The variables are saved per-domain, not per-account. To issue a new certificate, run: ```sh ./acme.sh --issue --dns dns_nsd -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2245) ----------------------------------- **[More APIs see here...](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2)** acme.sh-0.0~git20250417.7502af3/dnsapi2.md000066400000000000000000002535341500024665000173000ustar00rootroot00000000000000- [76. Use Schlundtech](#dns_schlundtech) - [77. Use your one.com credentials as you would login into the control panel.](#dns_one) - [78. Use AcmeProxy DNS API](#dns_acmeproxy) - [79. Use internetbs.net API](#dns_internetbs) - [80. Use durabledns.com API](#dns_durabledns) - [81. Use reg.ru API](#dns_regru) - [82. Use Vultr DNS API to automatically issue cert](#dns_vultr) - [83. Use jdcloud.com DNS API to automatically issue cert](#dns_jd) - [84. Use hexonet.net DNS API to automatically issue a cert](#dns_hexonet) - [85. Use Domeneshop DNS API to automatically issue a cert](#dns_domeneshop) - [86. Use OPNsense embedded API to automatically issue cert](#dns_opnsense) - [87. Use the RcodeZero API to automatically issue cert](#dns_rcode0) - [88. Use MailinaBox](#dns_miab) - [89. Use nic.ru DNS](#dns_nic) - [90. Use Leaseweb.com domain API to automatically issue cert](#dns_leaseweb) - [91. Use variomedia.de domain API to automatically issue cert](#dns_variomedia) - [92. Use Plesk XML API to automatically issue cert](#dns_pleskxml) - [93. Use PDNS Manager API](#dns_pdnsmanager) - [94. Use Misaka.io domain API](#dns_misaka) - [95. Use easyDNS.net API to automatically issue a cert](#dns_easydns) - [96. Use CloudDNS API to automatically issue a cert](#dns_clouddns) - [97. Use dynv6 API to automatically issue a cert](#dns_dynv6) - [98. Use All-Inkl.com domain API to automatically issue cert](#dns_kas) - [99. Use Constellix domain API](#dns_constellix) - [100. Use Namemaster domain API](#dns_nm) - [101. Use HostingUkraine domain API](#dns_hostingukraine) - [102. Use ArvanCloud domain API](#dns_arvan) - [103. Use Joker.com domain API](#dns_joker) - [104. Use 1984Hosting domain API](#dns_1984hosting) - [105. Use Aruba domain API](#dns_aruba) - [106. Use TransIP domain API:](#dns_transip) - [107. Use dyndnsfree.de API](#dns_df) - [108. Use Njalla API](#dns_njalla) - [109. Use Vercel API](#dns_vercel) - [110. Use Hetzner DNS API](#dns_hetzner) - [111. Use kapper.net DNS API](#dns_kappernet) - [112. -------](-------) - [113. Use Shellrent API](#dns_shellrent) - [114. Use OpenStack domain API](#dns_openstack) - [115. Use Netlify API](#dns_netlify) - [116. Use Akamai Edge DNS API](#dns_edgedns) - [117. Use WEDOS DNS API](#dns_wedos) - [118. Use Websupport DNS API](#dns_websupport) - [119. Use infomaniak.com API](#dns_infomaniak) - [120. Use bookmyname.com API](#dns_bookmyname) - [121. Use anexia.com CloudDNS API](#dns_anx) - [122. Use Synology DSM Synology DNS Server API](#dns_synology_dsm) - [123. Use HuaweiCloud API](#dns_huaweicloud) - [124. Use Simply.com API](#dns_simply) - [125. Use World4You API](#dns_world4you) - [126. Use Scaleway API](#dns_scaleway) - [128. Use RackCorp API](#dns_rackcorp) - [129. Using the IONOS domain API](#dns_ionos) - [130. Using the Porkbun API](#dns_porkbun) - [131. Using the Aurora API](#dns_aurora) - [132. Using the Azion DNS API](#dns_azion) - [133. Using Oracle Cloud Infrastructure DNS](#dns_oci) - [134. Utilisation de l'API DNS Hostline Hébergement VPS](#dns_hostline) - [135. Use Veesp domain API](#dns_veesp) - [136. Use cPanel DNS systems](#dns_cpanel) - [137. Use ISPMan domain API](#dns_ispman) - [138. Use dnsHome.de DNS API](#dns_dnshome) - [139. Use mythic-beasts.com DNS API](#dns_mythic_beasts) - [140. Use s-dns.de API](#dns_sdns) - [141. Using the united-domains reselling DNS API](#dns_udr) - [142. Using the curanet DNS API](#dns_curanet) - [143. Use ArtFiles.de DNS API](#dns_artfiles) - [144. Use Geoscaling.com DNS2](#dns_geoscaling) - [145. Use fornex.com API](#dns_fornex) - [146. Use DNS.Services API](#dns_dnsservices) - [147. Use Nodion DNS API](#dns_nodion) - [148. Use dns.la API](#dns_la) - [149. Use Yandex Cloud DNS API](#dns_yc) - [150. Use Bunny DNS API to automatically issue cert](#dns_bunny) - [151. Use Selfhost DNS API](#dns_selfhost) - [152. Use rage4 DNS API](#dns_rage4) - [153. Use GCore DNS API](#dns_gcore) - [154. Use dynadot DNS API](#dns_dynadot) - [155. Use IPv64 DNS API](#dns_ipv64) - [156. Use Nanelo DNS API](#dns_nanelo) - [157. Use Google Domains DNS API](#dns_googledomains) - [158. Use DNSExit API](#dns_dnsexit) - [159. Use Lima-City (Trafficplex)](#dns_limacity) - [160. Use TencentCloud (DNSPod) API](#dns_tencent) - [161. Use Samba AD DC API](#dns_samba) - [162. Use West.cn API](#dns_west_cn) - [163. Use hosttech API](#dns_hosttech) - [164. Use Alviy API](#dns_alviy) - [165. Use Timeweb Cloud DNS API](#dns_timeweb) - [166. Use myLoc.de / webtropia.com DNS API](#dns_myloc) - [167. Use Yandex 360 for Business DNS API](#dns_yandex360) - [168. Use HE DNS DDNS API](#dns_he_ddns) - [169. Using the IONOS Cloud DNS API](#dns_ionos_cloud) - [170. Use omg.lol API](#dns_omglol) - [171. Use Power-MailinaBox](#dns_pmiab) - [172. Use Technitium DNS Server API](#dns_technitium) - [173. Use ZoneEdit DNS API](#dns_zoneedit) - [174. Use Anikeen Cloud DNS API](#dns_anikeen) - [175. Use mijn.host DNS API](#dns_mijnhost) - [176. Use OpenProvider (REST) DNS API](#dns_openprovider_rest) - [177. Use Beget.com DNS API](#dns_beget) - [178. Use FreeMyIP DNS API](#dns_freemyip) - [179. Use Area-7 DNS API](#dns_area7) - [180. Use HestiaCP DNS API](#dns_hestiacp) - [181. Use Netim DNS API](#dns_netim) - [182. Use Spaceship DNS API](#dns_spaceship) - [182. Use Edgecenter DNS API](#dns_edgecenter) - [Use custom API](#dns_myapi) - [Use lexicon DNS API](#dns_lexicon) ## 76. Use Schlundtech [Schlundtech](https://www.schlundtech.de/) offers a [xml api](https://www.schlundtech.de/services/xml-gateway/) with your standard login credentials, set them like so: ```sh export SCHLUNDTECH_USER="yourusername" export SCHLUNDTECH_PASSWORD="password" ``` Then you can issue your certificates with: ```sh ./acme.sh --issue --dns dns_schlundtech -d example.com -d *.example.com ``` The `SCHLUNDTECH_USER` and `SCHLUNDTECH_PASSWORD` settings will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2246) ## 77. Use your one.com credentials as you would login into the control panel. ```sh export ONECOM_User="" export ONECOM_Password="youremail@example.com" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_one -d example.com -d *.example.com ``` Note: It's no longer possible to add TXT Records with the Name `_acme-challenge` to the base Domain. To override the fallback value, you must use a CNAME and proxy it. For example: CNAME _acme-challenge.yourdomain.com => proxy_acme-challenge.yourdomain.com The TXT Records have to be created on `proxy_acme-challenge.yourdomain.com`. Since the default CNAME TTL is 3600 seconds, it is recommended to leave the CNAME record. But if you would like to use the build-in SSL (for your Web-Site etc.) from one.com, you have to delete the Record. You can set `ONECOM_KeepCnameProxy` to keep the CNAME record. ```sh export ONECOM_KeepCnameProxy=1 ``` By default the CNAME record will be removed. The `ONECOM_User`,`ONECOM_Password` and `ONECOM_KeepCnameProxy` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2103) ## 78. Use AcmeProxy DNS API [Acmeproxy](https://github.com/mdbraber/acmeproxy/) can be used to as a single host in your network to request certificates through a DNS API. Clients can connect with one single host (the acmeproxy) so you don't need to store your DNS API credentials on every single host that wants to request a certificate. ```sh export ACMEPROXY_ENDPOINT="https://acmeproxy.yourhost.com:9096" export ACMEPROXY_USERNAME="username" export ACMEPROXY_PASSWORD="password" ``` Then you can issue your certificates with: ```sh ./acme.sh --issue --dns dns_acmeproxy -d example.com -d *.example.com ``` The `ACMEPROXY_ENDPOINT`, `ACMEPROXY_USERNAME` and `ACMEPROXY_PASSWORD` settings will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2251) ## 79. Use internetbs.net API Create an API token in your internetbs.net account. Set your API token: ```sh export INTERNETBS_API_KEY="..." export INTERNETBS_API_PASSWORD="..." ``` To issue a certificate run: ```sh ./acme.sh --issue --dns dns_internetbs -d example.com -d *.example.com ``` The `INTERNETBS_API_KEY` and `INTERNETBS_API_PASSWORD` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2261) ## 80. Use durabledns.com API Create an API token in your durabledns.com account. Set your API token: ```sh export DD_API_User="..." export DD_API_Key="..." ``` To issue a certificate run: ```sh ./acme.sh --issue --dns dns_durabledns -d example.com -d '*.example.com' ``` The `DD_API_User` and `DD_API_Key` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2281) ## 81. Use reg.ru API Set your API credentials: ```sh export REGRU_API_Username='test' export REGRU_API_Password='test' ``` To issue a certificate run: ```sh ./acme.sh --issue --dns dns_regru -d 'example.com' -d '*.example.com' ``` The `REGRU_API_Username` and `REGRU_API_Password` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2336) RU: Установите свои учетные данные API: В [Настройки API](https://www.reg.ru/user/account/#/settings/api/) для авторизации устанавливаем пароль в настройках "Альтернативный пароль", и добавляем IP в "Диапазоны IP-адресов" для избежание ошибки ``` response='{ "charset" : "utf-8", "error_code" : "ACCESS_DENIED_FROM_IP", "error_params" : { "command_name" : "service/get_list" }, "error_text" : "Access to API from this IP denied", "messagestore" : null, "result" : "error" }' ``` Диапазоны IP-адресов acme-v02.api.letsencrypt.org - `172.65.32.248` для получения SSL и api.reg.ru - `194.58.116.30` для тхт записи _acme-challenge Для авторизатции в API выполните: ```sh export REGRU_API_Username='водим свой логин для входа на REG.RU' export REGRU_API_Password='водим пароль каторый настроили в настройках API для авторизации' ``` Для получения сертификата выполните: ```sh ./acme.sh --issue --dns dns_regru -d example.com -d *.example.com ``` Настройки для авторизации `REGRU_API_Username` и `REGRU_API_Password` будут сохранены в `~/.acme.sh/account.conf` и будут использоваться повторно при необходимости из конфига acme. Если вы обнаружите какие-либо ошибки в API reg.ru, сообщите об этом [здесь](https://github.com/acmesh-official/acme.sh/issues/2336) ## 82. Use Vultr DNS API to automatically issue cert You'll need an API key for your Vultr account which you can find [under the Account settings](https://my.vultr.com/settings/#settingsapi). And you'll want to ensure the API key is allowed for any IPs you might be using acme.sh with. Vultr supports creating sub-accounts with limited permissions, and it's a good idea to create a sub-account with only the 'Manage DNS' permission and use an API key from that sub-account. ```sh export VULTR_API_KEY="" ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_vultr -d example.com -d *.example.com ``` The `VULTR_API_KEY` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2374) ## 83. Use jdcloud.com DNS API to automatically issue cert 支持京东云 jdcloud.com 的免费dns服务. 请先登陆控制台获取 api key id 和 api key secret: https://uc.jdcloud.com/account/accesskey ```sh export JD_ACCESS_KEY_ID="" export JD_ACCESS_KEY_SECRET="" ``` 然后生成证书: ```sh ./acme.sh --issue --dns dns_jd -d example.com -d *.example.com ``` `JD_ACCESS_KEY_ID` 和 `JD_ACCESS_KEY_SECRET` 会自动保存在这里 `~/.acme.sh/account.conf`, 下次再生成证书时, 可以自动重用. 高级选项: 1. 默认使用的是 `cn-north-1` 区域. 目前不需要改动, 如果需要改的话, 再生成证书之前执行: ```sh export JD_REGION="cn-north-1" # 这里写你要改的区域 ``` 有 bug 的话可以报到这里: https://github.com/acmesh-official/acme.sh/issues/2388 ## 84. Use hexonet.com DNS API to automatically issue a cert Login to hexonet.net. Create a role user in your [Account -> Settings -> ShareAccess](https://account.hexonet.net/#/role-accounts) Set the Access Control like bellow: ``` QueryDNSZoneRRList(dnszone=*):ALLOW UpdateDNSZone():ALLOW ``` Remember the role id and role password. ```sh export Hexonet_Login="user!role" export Hexonet_Password="" ``` For example: My username is `neilpang`, my role id is: `testid`. So I use the following format: ```sh export Hexonet_Login='neilpang!testid' ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_hexonet -d example.com -d *.example.com ``` The `Hexonet_Login` and `Hexonet_Password` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2389) ## 85. Use Domeneshop DNS API to automatically issue a cert You'll have to get a Domeneshop API key and secret (https://api.domeneshop.no/docs/). ```sh export DOMENESHOP_Token="" export DOMENESHOP_Secret="" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_domeneshop -d example.com -d *.example.com ``` The `DOMENESHOP_Token` and `DOMENESHOP_Secret` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2457) ## 86. Use OPNsense embedded API to automatically issue cert First you need to login to your OPNsense account and create an API Key for a user with access to the Bind service. https://docs.opnsense.org/development/api.html ```sh export OPNs_Host="opnsense.example.com" export OPNs_Port="443" export OPNs_Key="qocfU9RSbt8vTIBcnW8bPqCrpfAHMDvj5OzadE7Str+rbjyCyk7u6yMrSCHtBXabgDDXx/dY0POUp7ZA" export OPNs_Token="pZEQ+3ce8dDlfBBdg3N8EpqpF5I1MhFqdxX06le6Gl8YzyQvYCfCzNaFX9O9+IOSyAs7X71fwdRiZ+Lv" export OPNs_Api_Insecure=0 ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_opnsense -d example.com -d *.example.com ``` The `OPNs_Host`, `OPNs_Port`, `OPNs_Key`, `OPNs_Token` and `OPNs_Api_Insecure` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2480) ## 87. Use the RcodeZero API to automatically issue cert First you need to login to your RcodeZero account, enable the REST API and generate an ACME API token. Only the ACME API token will work wih acme.sh. It has limited access and could only be used to add/remove challenges to the zones. https://my.rcodezero.at/ → Settings → API ```sh export RCODE0_API_TOKEN="acme_1232342342343OEH1G1gDcKNMsN7mx9EZgSU6AX79u5KRSxWnC" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_rcode0 -d example.com -d *.example.com ``` The `RCODE0_API_TOKEN` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. The RcodeZero API driver supports two addtional environment variables ```sh export RCODE0_URL="https://my.rcodezero.at" ``` Use a different RcodeZero API Endpoint (e.g. the RcodeZero Testsystem) ```sh export RCODE0_TTL=60 ``` Use a different TTL for the generated records Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2490) ## 88. Use MailinaBox Use the Mail-In-a-Box (MIAB) Custom DNS REST API interface to MIAB DNS. You only need to set your MIAB login credentials and the fully qualified domain name of the MIAB Server. Suggest single quote over double quote to ensure characters are not interpreted by the shell - important for passwords. ```sh export MIAB_Username='your_MIAB_admin_username' export MIAB_Password='your_MIAB_admin_password' export MIAB_Server='FQDN_of_your_MIAB_Server' ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_miab -d example.com -d *.example.com ``` The `MIAB_Username`, `MIAB_Password` and `MIAB_Server` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2550) ## 89. Use nic.ru DNS You need to login to nic.ru account and register your application [here](https://www.nic.ru/manager/oauth.cgi?step=oauth.app_register). You need to define the following environment variables befor issuing a cert: * `NIC_Username` - login for site `nic.ru` in form `000000/NIC-D` * `NIC_Password` - password for site `nic.ru`. It may be administrative or technical password. [Details](https://www.nic.ru/help/use-of-administrative-and-technical-passwords-according-to-the-agreement_6148.html) * `NIC_ClientID` - your application identifier ([details](https://www.nic.ru/help/oauth-server_5809.html)) * `NIC_ClientSecret` - your application secret * _`NIC_Token` is base64 encoded string `:`. **This variable is deprecated**. It is used for backward compatibility. If NIC_ClientID and NIC_ClientSecret are not defined, then they are calculated using old NIC_Token variable._ ```bash export NIC_Username='000000/NIC-D' export NIC_Password='xxxxxxxx' export NIC_ClientID='xxxxxxxx' export NIC_ClientSecret='xxxxxxxx' ``` To issue a cert: ```bash ./acme.sh --issue --dns dns_nic -d domain.com -d *.domain.com ``` The `NIC_Username`, `NIC_Password`, `NIC_ClientID` and `NIC_ClientSecret` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2547) Docs: * https://www.nic.ru/help/upload/file/API_DNS-hosting-en.pdf * https://www.nic.ru/help/oauth-server_5809.html ## 90. Use Leaseweb.com domain API to automatically issue cert First you need to login to your Leaseweb account to get your API Key. ```sh export LSW_Key="" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_leaseweb -d example.com -d *.example.com ``` The `LSW_Key` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2558) ## 91. Use variomedia.de domain API to automatically issue cert First you need to obtain your API Key from variomedia's customer support. ```sh export VARIOMEDIA_API_TOKEN="" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_variomedia -d example.com -d *.example.com ``` The `VARIOMEDIA_API_TOKEN` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2564) ## 92. Use Plesk XML API to automatically issue cert Before using the module, you must set your Plesk username and password, and the address of your Plesk XML API (sometimes called a URI, URL or web link). The URI usually looks similar to this: ``` https://address-of-my-plesk-server.net:8443/enterprise/control/agent.php ``` All commands are CASE SENSITIVE: ```sh export pleskxml_uri="address of my Plesk server's API" export pleskxml_user="my plesk username" export pleskxml_pass="my plesk password" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_pleskxml -d example.com -d *.example.com ``` The `pleskxml_uri`, `pleskxml_user` and `pleskxml_pass` will be saved in `~/.acme.sh/account.conf` and reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2577) ## 93. Use PDNS Manager API [PDNS Manager](https://pdnsmanager.org/) is a web frontend for [Power DNS](https://www.powerdns.com/). This script uses PDNS Manager API and its [Update via GET request](https://pdnsmanager.org/documentation/api/) method. So only single record update possible and no wildcards, for now. ```sh export PDNS_MANAGER_URL="https://mypdnsmanagerurl.nx" export PDNS_MANAGER_RECORDID="" export PDNS_MANAGER_PASSWORD="" ``` * Add your domain to PDNS Manager. * [Create a password](https://pdnsmanager.org/documentation/api/) for your record. Then issue a new certificate: ```sh ./acme.sh --issue --dns dns_pdnsmanager -d example.com -d *.example.com ``` ## 94. Use Misaka.io domain API Get your API token at https://console.misaka.io/settings ```sh export Misaka_Key="" ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_misaka -d example.com -d *.example.com ``` ## 95. Use easyDNS.net API to automatically issue a cert You need to sign up for API access [here](https://cp.easydns.com/manage/security/api/signup.php). Or select 'User' -> 'Security' from the top menu and select 'signup' in the 'easyDNS REST API' section after logging in to your account. API Docs: https://sandbox.rest.easydns.net:3001/ Note that initially you are only granted API access to a sandbox environment, not your live DNS settings. ```sh export EASYDNS_Token="xxxxxxxxxxxxxxx.xxxxxxxx" export EASYDNS_Key="apixxxxxxxxxxxxxx.xxxxxxxx" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_easydns -d example.com -d *.example.com ``` The `EASYDNS_Token` and `EASYDNS_Key` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2647) ## 96. Use CloudDNS API to automatically issue a cert Docs: https://github.com/vshosting/clouddns ```sh export CLOUDDNS_EMAIL="email@example.com" export CLOUDDNS_PASSWORD="xxxxxxxx" export CLOUDDNS_CLIENT_ID="xxxxxxxxxxxxxxxxxxxx" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_clouddns -d example.com -d *.example.com ``` The `CLOUDDNS_EMAIL`, `CLOUDDNS_PASSWORD` and `CLOUDDNS_CLIENT_ID` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2699) ## 97. Use dynv6 API to automatically issue a cert This uses the [HTTP REST API](https://dynv6.github.io/api-spec/). For this you will need a HTTP Token, which you can generate from the [dynv6 website](https://dynv6.com/keys). Use it with `export DYNV6_TOKEN="value"`. Alternatively you can use the [dynv6 SSH API](https://dynv6.com/docs/apis) to issue the certificate. You will need a ssh key to authenticate. You can specify your own key with `export KEY="path/to/keyfile"` or if no key is specified one will be created for you which you will have to add [here](https://dynv6.com/keys). In both cases the path to the keyfile will be saved for reuse. If both a SSH Key and a HTTP Token are specified the REST API will be used. To issue a cert use: ```sh ./acme.sh --issue --dns dns_dynv6 -d example.dynv6.net -d *.example.dynv6.net ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2702) ## 98. Use All-Inkl.com domain API to automatically issue cert You need your login credentials for All-Inkl (https://kas.all-inkl.com). ```sh export KAS_Login="" export KAS_Authdata="" export KAS_Authtype="plain" ``` Now you are able to issue a cert: ```sh ./acme.sh --issue --dns dns_kas -d example.com -d *.example.com ``` The `KAS_Login`, `KAS_Authtype` and `KAS_Authdata` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2715) ## 99. Use Constellix domain API Get your API credentials at https://manage.constellix.com/users ```sh export CONSTELLIX_Key="XXX" export CONSTELLIX_Secret="XXX" ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_constellix -d example.com -d *.example.com ``` The `CONSTELLIX_Key` and `CONSTELLIX_Secret` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2724) ## 100. Use Namemaster domain API Get your API credentials at https://namemaster.de DNS/API ```sh export NM_user="XXX" export NM_sha256="XXX" ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_nm -d example.com -d *.example.com ``` The `NM_user` and `NM_sha256` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 101. Use HostingUkraine domain API How get your API credentials: https://api.adm.tools/osnovnie-polozheniya/dostup-k-api/ ``` # Your login: HostingUkraine_Login="XXX" # Your api token: HostingUkraine_Token="XXX" ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_hostingukraine -d example.com -d *.example.com ``` The `HostingUkraine_Login` and `HostingUkraine_Token` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2683) ## 102. Use ArvanCloud domain API Get your API token at https://npanel.arvancloud.ir/profile/api-keys ```sh export Arvan_Token="" ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_arvan -d example.com -d *.example.com ``` The `Arvan_Token` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2796) ## 103. Use Joker.com domain API You must activate Dynamic DNS in Joker.com DNS configuration first. Username and password below refer to Dynamic DNS authentication, not your Joker.com login credentials. See https://joker.com/faq/content/11/427/en/what-is-dynamic-dns-dyndns.html. **NOTE:** This script does not support wildcard certificates, because Joker.com API does not support adding two TXT records with the same subdomain. Adding the second record will overwrite the first one. See https://joker.com/faq/content/6/496/en/let_s-encrypt-support.html: > ... this request will replace all TXT records for the specified label by the provided content... Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2840) ```sh export JOKER_USERNAME="xxxx" export JOKER_PASSWORD="xxxx" ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_joker -d example.com -d *.example.com ``` The `JOKER_USERNAME` and `JOKER_PASSWORD` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. ## 104. Use 1984Hosting domain API https://1984.hosting/ does not provide an API to update DNS records (other than IPv4 and IPv6 dynamic DNS addresses). The `acme.sh` plugin therefore retrieves and updates domain TXT records by logging into the 1984Hosting website to read the HTML and posting updates as HTTP. The plugin needs to know your username and password for the 1984Hosting website. ```sh export One984HOSTING_Username="" export One984HOSTING_Password="" ``` You need only provide this the first time you run the `acme.sh` client with 1984Hosting validation and then again whenever you change your password at the 1984Hosting site. The `acme.sh` 1984Hosting plugin does not store your username or password, but rather saves an authentication token returned by 1984Hosting in `~/.acme.sh/account.conf` and reuses it when needed. Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_1984hosting -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2851) ## 105. Use Aruba domain API Get your API token following instruction here at https://admin.arubabusiness.it/DashBoard/WebApiGuide.aspx ```sh export ARUBA_TK="" export ARUBA_AK="" export ARUBA_AS="" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_aruba -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2994) ## 106. Use TransIP domain API: First you need to login to your TransIP account to get your [private key](https://www.transip.nl/cp/account/api/). ```sh export TRANSIP_Username="MyUserName" export TRANSIP_Key_File="private_key" ``` Note: TransIP is rather slow, so adding a `--dnssleep` of 300 might be advised. Note 2: if the DNS fails with something like ``` Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 60 == Info: SSL certificate problem: unable to get local issuer certificate ``` Then maybe the root CA of TransIP is NOT in your cacerts. You can check this manually with ```sh curl -vvI https://api.transip.nl ``` Currently, the root CA of TransIP is COMODO_RSA_Certification_Authority.crt you can add this trusted root CA with ``` --ca-bundle COMODO_RSA_Certification_Authority.crt ``` This script will create a new access token with a default lifetime of 30 minutes. Note that these tokens are by default IP-whitelisted and will not work if your IP is not whitelisted in the Transip control panel. If you cannot work with IP whitelisting, then make sure you create a key with `Only allow whitelisted IP's` unchecked and set the environment variable as follows: ```sh export TRANSIP_Token_Global_Key="true" ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_transip --dnssleep 300 -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2949) ## 107. Use dyndnsfree.de API ```sh export DF_user="XXX" export DF_password="XXX" ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_df -d example.com -d *.example.com ``` The `df_user` and `df_password` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2897) ## 108. Use Njalla API ```sh export NJALLA_Token="" ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_njalla -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2913) ## 109. Use Vercel API Obtain an account token from https://vercel.com/account/tokens. ```sh export VERCEL_TOKEN="" ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_vercel -d example.com -d *.example.com ``` ## 110. Use Hetzner DNS API First you need to create/obtain API tokens on your [Hetzner DNS console](https://dns.hetzner.com/settings/api-token). ```sh export HETZNER_Token="" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_hetzner -d example.com -d *.example.com ``` The `HETZNER_Token` settings will be saved in `[acme.sh-config-home-path]/account.conf` and will be reused when needed. The domain(s) zone_id(s) will be saved in `CERT_HOME/[domain]/[domain].conf` in order to avoid multiple `get_zone_id` requests two months later. > If you're not already using the new "gases" name servers (hydrogen, oxygen and helium) > don't forget to change the domain's whois ns section to them and wait about 24-48 Hours. > See [Hetzner wiki](https://docs.hetzner.com/dns-console/dns/general/what-has-changed). Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2943) ## 111. Use kapper.net DNS API Contact kapper.net support via support@kapper.net to get your kapper.net DNS Panel API Key and Secret. For initialization call following in commandline ```sh export KAPPERNETDNS_Key="yourKAPPERNETapikey" export KAPPERNETDNS_Secret="yourKAPPERNETapisecret" ``` You can start the acme.sh with following parameters for testing ```sh ./acme.sh --issue --dns dns_kappernet -d example.com -d *.example.com ``` Please replace `example.com` with the name of the domain you wish to create a certificate for. After the test you can replace your `kapper.net` DNS Panel API Key and Secret, it is stored in `~/.acme.sh/account.conf`. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2977) ## 112. ------- --------- ## 113. Use Shellrent API Shellrent API offers one method to automatically issue certs. First you need to login to your Shellrent account to get your API key. In order to use the token, you need to authorize your IP to have access to it. More Info on https://api.shellrent.com and https://guide.shellrent.com ```sh export SH_Username="usrXXXX" export SH_Token="" ``` Alternatively, if the certificate only covers a single zone, you can speed up the process by specify the SH_Domain_ID directly: ```sh export SH_Username="usrXXXX" export SH_Token="" export SH_Domain_ID="xxxxxxxxxxxxx" ``` Let's issue a cert now: ```sh ./acme.sh --issue --dns dns_shellrent -d example.com -d *.example.com ``` The SH_Username and SH_Token and SH_Domain_ID will be saved in ~/.acme.sh/account.conf and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2997) ## 114. Use OpenStack domain API This provider supports [OpenStack Designate](https://docs.openstack.org/designate) for creating DNS records. This provider requires the OpenStack Client (python-openstackclient) and Designate client (python-designateclient) be installed and available in your path. It also requires you use Keystone V3 credentials, which can be either password or application credentials provided as environment variables. Any other authentication method will not save your credentials for renewal. You will most likely want to source your OpenStack RC file to set your environment variables: ``` . openrc.sh ``` or manually like: ```sh export OS_AUTH_URL="https://keystone.example.com:5000/" export OS_USERNAME="" export OS_PASSWORD="" export OS_PROJECT_NAME="" export OS_PROJECT_DOMAIN_NAME="Default" export OS_USER_DOMAIN_NAME="Default" ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_openstack -d example.com -d *.example.com ``` Your OpenStack credentials will be saved to `~/.acme.sh/account.conf` and reused on renewal. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3054) ## 115. Use Netlify API Generate a Personal Access Token at https://app.netlify.com/user/applications Set your token for use with: ```sh export NETLIFY_ACCESS_TOKEN='' ``` Issue a cert with: ```sh ./acme.sh --issue --dns dns_netlify -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3088) ## 116. Use Akamai Edge DNS API This provider supports the [Akamai Edge DNS](https://developer.akamai.com/api/cloud_security/edge_dns_zone_management/v2.html) API for creating DNS records. This provider requires Akamai Open Edgegrid Credentials with EdgeDNS API access authorization. To create and establish your Akamai OPEN CREDENTIALS, see the [authorization](https://developer.akamai.com/legacy/introduction/Prov_Creds.html) and [credentials](https://developer.akamai.com/legacy/introduction/Conf_Client.html) sections of the Akamai Developer Get Started guide. The Akamai Open Edgegrid credentials must be specified as environment variables as follows: ```sh export AKAMAI_CLIENT_TOKEN="" export AKAMAI_ACCESS_TOKEN="" export AKAMAI_CLIENT_SECRET="" export AKAMAI_HOST="" ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_edgedns -d example.com -d *.example.com ``` Your Akamai Edgegrid credentials will be saved to `~/.acme.sh/account.conf` and reused on renewal. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3157) ## 117. Use WEDOS DNS API WEDOS DNS provider from the Czech Republic. DNS API implementation for WEDOS require your WEDOS's account to allow WAPI interface. You have to login to WEDOS administration, in setting allow WAPI interface (in days when this manual were written it was for free completely). Configure WAPI interface to XML interface and register the IP addresses (IPv4 and IPv6) of the server where you plan to use acme.sh. That is from the manual side. By doing this setting you should have WEDOS web account username and configured WAPI password. This must be configured to your acme.sh account in the first execution of acme.sh script. To save it to `~/.acme.sh/account.conf` (and for subsequent acme.sh executions) just execute following before first execution of acme.sh script. ```sh export WEDOS_Username="" export WEDOS_Wapipass="" ``` Then you can issue a certificates: ```sh ./acme.sh --issue --dns dns_wedos -d example.com -d *.examle.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3166). But before reporting run the acme.sh with `--debug 2` switch and append full acme.sh output to the issue report. ## 118. Use Websupport DNS API Obtain an api key and secret from https://admin.websupport.sk/en/auth/apiKey or https://admin.websupport.se/en/auth/security-settings ```sh export WS_ApiKey="" export WS_ApiSecret="" ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_websupport -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3486) ## 119. Use infomaniak.com API Infomaniak hosts a large number of domains and other hosted services. Create a token with Domain scope in the API dashboard at https://manager.infomaniak.com/v3//api/dashboard and export it as an environment variable: ```sh export INFOMANIAK_API_TOKEN="" ./acme.sh --issue --dns dns_infomaniak -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3188) ## 120. Use bookmyname.com API Bookmyname hosts domains and has a small API. Export your login/pass as an environment variable: ```sh export BOOKMYNAME_USERNAME="xxx" export BOOKMYNAME_PASSWORD="yyy" ./acme.sh --issue --dns dns_bookmyname -d example.com -d *.example.com --dnssleep 600 ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3209) ## 121. Use anexia.com CloudDNS API For DNS records managed via https://engine.anexia-it.com/clouddns Export your token as an environment variable: ```sh export ANX_Token='' ./acme.sh --issue --dns dns_anx -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3238) ## 122. Use Synology DSM Synology DNS Server API Note that in order the script to be working properly acme.sh should be installed on Synology itself. To issue a cert: ```sh ./acme.sh --issue --dns dns_synology_dsm -d example.com -d *.example.com ``` You can find more details [here](https://github.com/arabezar/acme.sh/wiki) Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3248) ## 123. Use HuaweiCloud API Export your credentials as an environment variable: About `DomainName` parameters see: https://support.huaweicloud.com/api-iam/iam_01_0006.html ```sh export HUAWEICLOUD_Username="" export HUAWEICLOUD_Password="" export HUAWEICLOUD_DomainName="" ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_huaweicloud -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3265) ## 124. Use Simply.com API Export your credentials, you will find your API key by logging in to your Simply.com account [here](https://www.simply.com/controlpanel/account/): ```sh export SIMPLY_AccountName="" export SIMPLY_ApiKey="" ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_simply -d example.com -d *.example.com ``` ## 125. Use World4You API Export your credentials as an environment variable: ```sh export WORLD4YOU_USERNAME="" export WORLD4YOU_PASSWORD="" ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_world4you -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3269) ## 126. Use Scaleway API First, you'll need to retrieve your [Api Key](https://www.scaleway.com/en/docs/generate-api-keys/) ```sh export SCALEWAY_API_TOKEN='xxx' ``` To issue a cert run: ```sh ./acme.sh --issue --dns dns_scaleway -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3295) ## 127. LS _removed_ ## 128. Use RackCorp API Export your credentials as an environment variable: ```sh export RACKCORP_APIUUID="UUIDHERE" export RACKCORP_APISECRET="SECRETHERE" ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_rackcorp -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3351) ## 129. Using the IONOS domain API Read [Getting Started](https://developer.hosting.ionos.de/docs/getstarted) to learn how to create an API key. Export your credentials as environment variables: ```sh export IONOS_PREFIX="..." export IONOS_SECRET="..." ``` To issue a certificate, execute: ```sh ./acme.sh --issue --dns dns_ionos -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3379) ## 130. Using the Porkbun API You must first log in to your Porkbun domain management dashboard and enable API access under details for your domain. Read [Getting Started](https://porkbun.com/api/json/v3/documentation) to learn how to create an API key. Export your credentials as environment variables: ```sh export PORKBUN_API_KEY="..." export PORKBUN_SECRET_API_KEY="..." ``` To issue a certificate, execute: ```sh ./acme.sh --issue --dns dns_porkbun -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3450) ## 131. Using the Aurora API [PCextreme B.V.](https://www.pcextreme.nl/) is a Dutch cloud provider offering cloud services under the family name Aurora. Head over to [DNS & Health Checks > Users](https://cp.pcextreme.nl/auroradns/users) to get your API credentials. Export your credentials as environment variables: ```sh export AURORA_Key="..." export AURORA_Secret="..." ``` To issue a certificate, execute: ```sh ./acme.sh --issue --dns dns_aurora -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3459) ## 132. Using the Azion DNS API https://www.Azion.com/ is a Edge Computing Platform to build modern applications at edge. This API reflects the [Intelligent DNS](https://www.azion.com/en/documentation/products/intelligent-dns/) product. Read this [documentation](https://www.azion.com/en/documentation/products/api/v3/) to create a username/password and permissions to use this plugin. Export your username/password as environment variables: ```sh export AZION_Email="user@example.com" export AZION_Password="password" ``` To issue a certificate, execute: ```sh ./acme.sh --issue --dns dns_azion -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3555) ## 133. Using Oracle Cloud Infrastructure DNS See: https://github.com/acmesh-official/acme.sh/wiki/How-to-use-Oracle-Cloud-Infrastructure-DNS ## 134. Utilisation de l'API DNS Hostline Hébergement VPS Créer un token API sur votre compte [Hostline Hébergement VPS](https://www.hostline.fr). Ajouter les variables API suivantes : ```sh export HOSTLINE_Token="xxx" # (obligatoire) export HOSTLINE_Url="https://api.hostline.fr" # (optionnel) export HOSTLINE_Ttl="60" # ttl custom record (optionnel) ``` Pour générer un certificat exécuter la commande correspondante à votre cas : ```sh ./acme.sh --issue --dns dns_hostline -d example.com -d *.example.com ``` Les variables `HOSTLINE_Token`, `HOSTLINE_Url` (optionnel) et `HOSTLINE_Ttl` (optionnel) doivent être définies dans le fichier `/root/.acme.sh/account.conf`. Si vous rencontrez un problème sur l'API Hostline Hébergement VPS, merci de rapporter votre problème sur le lien suivant: https://github.com/acmesh-official/acme.sh/issues/3675 ## 135. Use Veesp domain API [Veesp](https://veesp.com/) offers HTTP REST [API](https://secure.veesp.com/userapi#dns-82) to manage vital details of account and services like DNS. Your standard login credentials is needed: ```sh export VEESP_User="username@domain.com" export VEESP_Password="password" ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_veesp -d example.com -d *.example.com ``` The `VEESP_User` and `VEESP_Password` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3712) ## 136. Use cPanel DNS systems First you need to log into the cPanel interface and generate an API key for your account (under Security -> Manage API Tokens). Then set your username, api token and hostname: ```sh export cPanel_Username="username" export cPanel_Apitoken="apitoken" export cPanel_Hostname="https://hostname:port" ``` example ```sh export cPanel_Username="myadminuseratnordicway" export cPanel_Apitoken="CXJ8HRXFNS363RQ71Z51TKM9KTHRFZVE" export cPanel_Hostname="https://cp04.nordicway.dk:2083" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_cpanel -d example.com -d *.example.com ``` See https://api.docs.cpanel.net/cpanel/introduction/#cpanel-or-webmail-session-url-1 regarding cPanel ports. The `cPanel_Username`, `cPanel_Apitoken` and `cPanel_Hostname` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3732) ## 137. Use ISPMan domain API !!! IMPORTANT: Make sure the version of ISPMan supports TXT records !!! The `dns_ispman.sh` api Adds & Deletes domain TXT records by authenticating into the [ISPMan](http://ispman.sourceforge.net/) Customer Control Panel and executing related HTTP POST & GET requests. The `dns_ispman.sh` api requires your `` and `` for authentication: ```sh export ISPMan_Username="" export ISPMan_Password="" ``` The `ISPMan_Username` and `ISPMan_Password` will be saved in `$LE_WORKING_DIR/account.conf` and will be reused for certificate renewals. Ok, let's issue a cert: ```sh ./acme.sh --issue --dns dns_ispman -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3751) ## 138. Use dnsHome.de DNS API ```sh export DNSHOME_Subdomain="" export DNSHOME_SubdomainPassword="" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_dnshome -d subdomain.ddnsdomain.tld ``` The `DNSHOME_Subdomain` and `DNSHOME_SubdomainPassword` will be saved in the domain conf and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3819) ## 139. Use mythic-beasts.com DNS API First obtain you API key from the control panel. ```sh export MB_AK="" export MB_AS="" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_mythic_beasts -d example.com -d *.example.com ``` The credentials will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3848) ## 140. Use s-dns.de API First generate your dns zone key. Open your existing nameserver entry, click on [Passwort für dynamic DNS generieren] and save your zone. This generates a new key for your zone. ```sh export SDNS_ZONE_KEY="" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_sdns -d example.com -d *.example.com ``` S-dns nameservers use anycast. It is therefore possible that the server next to your location already provides the new record, while the CA reaches another one that does not have the TXT record yet. To avoid such timing errors the `--dnssleep` flag can be set to a value of 240 seconds. ```sh ./acme.sh --issue --dns dns_sdns -d example.com -d *.example.com --dnssleep 240 ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3917) ## 141. Using the united-domains reselling DNS API Create an account at [ud reselling](https://www.ud-reselling.com/). There is no option to use an API key, so you just need to set your credentials as environment variables: ```sh export UDR_USER="..." export UDR_PASS="..." ``` To issue a certificate, execute: ```sh ./acme.sh --issue --dns dns_udr -d example.com -d *.example.com ``` The `UDR_USER` and `UDR_PASS` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3923) ## 142. Using the curanet DNS API Login to your curanet account, create a new API Application, and use client_id and secret as shown below ```sh export CURANET_AUTHCLIENTID="..." export CURANET_AUTHSECRET="..." ``` To issue a certificate, execute: ```sh ./acme.sh --issue --dns dns_curanet -d example.com -d *.example.com ``` The `CURANET_AUTHCLIENTID` and `CURANET_AUTHSECRET` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3933) ## 143. Use ArtFiles.de DNS API First, verify that API access is already enabled: 1. Go to ArtFiles.de's **DCP** (Domain Control Panel). 2. Click **Passwords** in the left menu. 3. To the menu's right, the drop-down menu for **Active** is either `active` or `inactive`. 4. If **Active** is already set to `active`, skip this step. Otherwise, enter your desired password into both text boxes, save it somewhere else (e. g. Firefox, KeePass, etc.) & click **Apply** below. 5. Copy **Username**'s value, i.e. the one that starts with `api` & then continues with your account number which is something like `a12345678`. Export `AF_API_USERNAME` & `AF_API_PASSWORD` only once (saved into domain's config file upon 1st successful script run): ```sh export AF_API_USERNAME="api12345678" export AF_API_PASSWORD="apiPassword" ``` To issue a certificate, execute: ```sh ./acme.sh --issue --dns dns_artfiles -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/4718) ## 144. Use Geoscaling.com DNS2 Create an account at [Geoscaling](https://www.geoscaling.com/). Set your credentials as environment variables: ```sh export GEOSCALING_Username="..." export GEOSCALING_Password="..." ``` To issue a certificate, execute: ```sh ./acme.sh --issue --dns dns_geoscaling -d example.com -d *.example.com ``` The `GEOSCALING_Username` and `GEOSCALING_Password` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3969) ## 145. Use fornex.com API Get an API key in your fornex.com account page. Then ```sh export FORNEX_API_KEY="" ``` To issue a cert, run command: ```sh ./acme.sh --issue --dns dns_fornex -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/3998) ## 146. Use DNS.Services API Use your credentials ```sh export DnsServices_Username="user@example.com" export DnsServices_Password="" ``` To issue a cert, run command: ```sh ./acme.sh --issue --dns dns_dnsservices -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/4152) ## 147. Use Nodion DNS API You are able to create a free account on https://app.nodion.com and add an API key used by acme.sh by visiting the [settings page](https://app.nodion.com/user/security). Please take this token and set it as env variable. ```sh export NODION_API_KEY="" ``` To issue a certificate, execute: ```sh acme.sh --issue --dns dns_nodion -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/4157) ## 148. Use dns.la API Use your credentials ```sh export LA_Id="" export LA_Key="" ``` To issue a cert, run command: ```sh ./acme.sh --issue --dns dns_la -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/4257) ## 149. Use Yandex Cloud DNS API Create a new service account with role `dns.editor` and [create authorized key](https://cloud.yandex.com/en-ru/docs/iam/operations/authorized-key/create) for him. Required parameters: ```sh export YC_Folder_ID="YC Folder ID" export YC_SA_ID="Service Account ID" export YC_SA_Key_ID="Service Account IAM Key ID" # You need use YC_SA_Key_File_PEM_b64 or YC_SA_Key_File_Path export YC_SA_Key_File_PEM_b64="Base64 content of private.key" export YC_SA_Key_File_Path="/path/to/private.key" ``` Optional parameters: ```sh export YC_Zone_ID="DNS Zone ID" ``` Now you can issue a cert: ```sh ./acme.sh --issue --dns dns_yc -d example.com -d *.example.com ``` Both, `YC_Folder_ID`, `YC_SA_ID`, `YC_SA_Key_ID`, `YC_SA_Key_File_PEM_b64` or `YC_SA_Key_File_Path` and `YC_Zone_ID` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/4210) ## 150. Use Bunny DNS API to automatically issue cert Find your API key at https://panel.bunny.net/account Then export the key: ```sh export BUNNY_API_KEY="your-api-key-goes-here" ``` Then you can issue a cert: ```sh ./acme.sh --issue --dns dns_bunny -d example.com -d *.example.com ``` The `BUNNY_API_KEY` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/4296) ## 151. Use Selfhost DNS API - create a new TXT record for a subdomainname with the needed prefix e.g. "_acme-challenge.example.com" (default) or "alias.example.com" (dns alias mode) - for wildcard subdomains add a second TXT record for the identical subdomainname - edit the TXT record and note the ID in (...) behind the subdomainname - export each subdomainname (including the prefix) and the corresponding record IDs in SELFHOSTDNS_MAP like "subdomainname:RID1:RID2" - at least one RID must be set, up to two are supported for wildcard subdomains - each entry must be seperated by a space - export username and password in SELFHOSTDNS_USERNAME and SELFHOSTDNS_PASSWORD _Note: For `username` you have to use your account / customer number. You can find them in any invoice or on the right top of the selfhost dashboard._ ```sh export SELFHOSTDNS_USERNAME="myname" export SELFHOSTDNS_PASSWORD="mypass" export SELFHOSTDNS_MAP="_acme-challenge.example.com:12345:98765 alias.example.com:11111" acme.sh --issue --dns dns_selfhost -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/4291) ## 152. Use rage4 DNS API Use your credentials ```sh export RAGE4_TOKEN="example-token" export RAGE4_USERNAME="example@user.local" ``` To issue a cert, run command: ```sh ./acme.sh --issue --dns dns_rage4 -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/4306) ## 153. Use GCore DNS API Login to your [GCore](https://accounts.gcore.com/profile/api-tokens) account and create an API Key. ```sh export GCORE_Key='' ``` To issue a cert, run command: ```sh ./acme.sh --issue --dns dns_gcore -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/4460) ## 154. Use dynadot DNS API PENDING Pull Request: https://github.com/acmesh-official/acme.sh/pull/4510 **Please read the comments in `dnsapi/dns_dynadot.sh` to understand the issues and limitations with dynadot's api before reporting any bugs and for more information on the options below** Login to to your dynadot account and create an api token ```sh DYNADOTAPI_Token="your_api_token" ``` Optional settings: ```sh DYNADOT_ADD_DNS_SLEEP=1800 DYNADOT_REMOVE_DNS_SLEEP=1800 DYNADOTAPI_SKIP_REMOVE=SKIP DYNADOTAPI_API_RETRIES=5 DYNADOTAPI_RETRY_SLEEP=30 ``` * The `--dnssleep` command line argument specifies the amount of sleep before requesting validation of records. When adding two text records, that sleep only occurs after both records have been added. The sleep settings above affect each dynadot operation. * `DYNADOT_ADD_DNS_SLEEP` is the number of seconds to sleep after adding a TXT record (for wildcard domains this will happen twice before validation). Recommended to set this at 1800 or higher if adding multiple records is required for your request or when making back to back requests. * `DYNADOTAPI_SKIP_REMOVE=SKIP` will skip removing TXT records. This is useful to save wait time when making multiple calls, however, TXT records will need to be manually removed after the process completes. * `DYNADOT_REMOVE_DNS_SLEEP` is the number of seconds to sleep after removing a TXT record. Recommended to set this at 1800 or higher if adding multiple records is required for your request or when making back to back requests. This is not required when using `DYNADOTAPI_SKIP_REMOVE=SKIP` * `DYNADOTAPI_API_RETRIES` number of times to attempt a DYNADOT api call. * `DYNADOTAPI_RETRY_SLEEP` sleep time between DYNADOT api calls (only applied if a call fails and DYNADOTAPI_API_RETRIES is set great than 1) Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/4523) ## 155. Use IPv64 DNS API Login to your [IPV64](https://ipv64.net/account.php?login) Account and copy your API Key. ```sh export IPv64_Token="your_ipv64_api_key" ``` To issue a cert, run command: ```sh ./acme.sh --issue --dns dns_ipv64 -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/4419) ## 156. Use Nanelo DNS API Login to your https://nanelo.com Account, navigate to Settings > API Keys and generate a new API Key. Copy it and set it like the following: ```sh export NANELO_TOKEN="" ``` To issue a cert, run the following command: ```sh ./acme.sh --issue --dns dns_nanelo -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/4519) ## 157. Use Google Domains DNS API Visit https://domains.google.com/registrar/ and click "Manage" on the domain. Then, in the Security settings, generate an access token for the ACME DNS API. Save this access token as it is only displayed once. ```sh export GOOGLEDOMAINS_ACCESS_TOKEN="" ``` To issue a cert, run the following: ```sh ./acme.sh --issue --dns dns_googledomains -d example.com -d *.example.com ``` The script tries to infer the zone registered with Google Domains by matching the domain against the Google Domains API. To manually specify the zone, do the following prior to running the issuing command: ```sh export GOOGLEDOMAINS_ZONE="google-domains-zone" ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/4545) ## 158. Use DNSExit API to automatically issue cert You'll need an API key for your DNSExit account which you can find under your Account Profile. You will also need your account login (username and password). ```sh export DNSEXIT_API_KEY="" export DNSEXIT_AUTH_USER="" export DNSEXIT_AUTH_PASS="" ``` To issue a cert, run the following: ```sh ./acme.sh --issue --dns dns_dnsexit -d example.com -d *.example.com ``` The login variables will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/4719). ## 159. Use Lima-City API to automatically issue cert You'll need an API key for your Lima-City account which you can find under Account Section in your User control panel. The API key must have following roles: dns.admin, domains.reader ```sh export LIMACITY_APIKEY="" ``` To issue a cert, run the following: ```sh ./acme.sh --issue --dns dns_limacity -d example.com -d *.example.com ``` The login variables will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/4758). ## 160. Use TencentCloud (DNSPod) API Please visit https://console.cloud.tencent.com/cam/capi to obtain the API key. ```sh export Tencent_SecretId="" export Tencent_SecretKey="" ``` To issue a cert, run the following: ```sh ./acme.sh --issue --dns dns_tencent -d example.com -d *.example.com ``` The login variables will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Docs: * https://cloud.tencent.com/document/product/302/105900 Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/4781) ## 161. Use Samba AD DC This API requires you to have `samba-tool` available, you don't need the full samba installation on a remote machine (if the machine you use to generate the certificate isn't the same as the Samba AD DC). On Debian, you can get it with the `samba-common-bin` package. Then you need to provide the host, username and password of an administrator to change the DNS settings: ```sh export SAMBA_HOST=dc1.example.com export SAMBA_USER=Administrator export SAMBA_PASS=MyAdminP@ssword ``` Then you can issue your certificates with: ```sh ./acme.sh --issue --dns dns_samba -d example.com -d *.example.com ``` Or even in 1 line: ```sh SAMBA_HOST=dc1.example.com SAMBA_USER=Administrator SAMBA_PASS=MyAdminP@ssword ./acme.sh --issue --dns dns_samba -d example.com -d *.example.com ``` The `SAMBA_HOST`, `SAMBA_USER` and `SAMBA_PASS` settings will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/4852) ## 162. Use West.cn API Please visit https://www.west.cn/manager/API/APIconfig.asp to obtain the Plaint API key. ` = md5()` ```sh export WEST_Username="" export WEST_Key="" ``` To issue a cert, run the following: ```sh ./acme.sh --issue --dns dns_west_cn -d example.com -d *.example.com ``` The login variables will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/4894) ## 163. Use Hosttech API Create an DNS API token in hosttech portal (DNS editor). Set your API key: ```sh export Hosttech_Key='xxx' ``` To issue a certificate run: ```sh ./acme.sh --issue --dns dns_hosttech -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/4900) ## 164. Use Alviy.com domain API to automatically issue cert First you need to register to your account to get your API Key and Secret. https://cloud.alviy.com/profile/ API token is creating automatically. ```sh export Alviy_token="" ``` Ok, let's issue a cert now: ```sh ./acme.sh --issue --dns dns_alviy -d example.com -d *.example.com ``` The `Alviy_token` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/5115) ## 165. Use Timeweb Cloud DNS API To begin, acquire a Timeweb Cloud API JWT token. You can obtain one via the [Timeweb Cloud control panel](https://timeweb.cloud/my/api-keys). Next, provide the JWT token to the script using one of two methods: * As the "TW_Token" variable. For example: ```sh export TW_Token='eyJhbG...zUxMiIs' ``` * As a "TW_Token" entry in acme.sh account configuration file (located at ~/.acme.sh/account.conf by default). For example, `TW_Token='eyJhbG...zUxMiIs'` Finally, сonsider the following command as an example of how to issue a certificate using the ACME DNS-01 challenge: ```sh ./acme.sh --issue --dns dns_timeweb -d example.com,*.example.com,foo.bar.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/5140). ## 166. Use myLoc.de / webtropia.com DNS API First, you need a domain hosted at myLoc.de or webtropia.com. A Webtropia also allows to use the myloc.de API. You need to register a token via the [myLoc.de website](https://zkm.myloc.de/s/api/token) or the [Webtropia.com website](https://zkm.webtropia.com/s/api/token). As the API does not allow to match domain names to zones yet, the zone has to be set manually if you plan to use subdomains. You can set the zone as well as the token using environment variables: ```sh export MYLOC_token=aabbccddeeffgghhiijjkkllmmnnjjkkllmmnnooppqqrrsstt export MYLOC_zone=example.com ``` If `MYLOC_zone` is not set, it will be guessed by stripping the `_acme-challenge.` prefix from the domains being processed. This may not match the zone, for example for issueing certificates for `sub1.example.com`, the zone probably is `example.com`. Now, use the dns_myloc backend to issue and renew certificates using DNS-01: ```sh ./acme.sh --issue --dns dns_myloc -d example.com,*.example.com,foo.bar.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/5193). ## 167. Use Yandex 360 for Business DNS API ### a. Set up OAuth application: 1. Log in as an organization administrator on Yandex. 2. [Create an OAuth application at Yandex ID](https://oauth.yandex.ru/client/new). 3. Choose "Web services" platform. 4. Set Redirect URI to `https://oauth.yandex.ru/verification_code`. 5. Select the following permissions: - "Manage DNS records" (directory:manage_dns) - "Read organization data" (directory:read_organization) (optional if the user exports the YANDEX360_ORG_ID variable manually) - "Read organization domain data" (directory:read_domains) 6. Save the Client ID and Client Secret. ### b. Obtain Yandex 360 Organization ID: *This step is optional as the Organization ID can be obtained automatically. However, the user can specify it manually as described below.* 1. After setting up the OAuth application, [visit Yandex 360 for Business Administration](https://admin.yandex.ru/). 2. In the upper-left corner of the page, select the correct organization from the list if you have multiple organizations. 3. In the lower-left corner of the page, find and note the Organization ID. ### c. Set up environment variables: Depending on whether you are using OAuth or a manually obtained access token, export the appropriate variables: #### i. Using OAuth (recommended): Export the following variables: ``` export YANDEX360_CLIENT_ID="your_client_id" export YANDEX360_CLIENT_SECRET="your_client_secret" export YANDEX360_ORG_ID="your_organization_id" # optional if directory:read_organization permission is granted ``` #### ii. Manually obtained access token: 1. Obtain an access token manually: - Go to: `https://oauth.yandex.ru/authorize?response_type=token&client_id=` - Replace `` with your OAuth application's Client ID. - Authorize and obtain the token. 2. Export the following variables: ``` export YANDEX360_ACCESS_TOKEN="your_access_token" export YANDEX360_ORG_ID="your_organization_id" # optional if directory:read_organization permission is granted ``` ### d. Issue/renew certificate: Use the `acme.sh` command with the `--dns dns_yandex360` parameter. For example: ``` ./acme.sh --issue --dns dns_yandex360 --dnssleep 600 -d example.com -d *.example.com ``` When using OAuth you will need to complete a one-time authorization procedure: 1. On first run, the script will initiate the device authorization process. 2. You'll be prompted to visit a URL and enter a code for authorization. 3. After successful authorization, the access token will be obtained automatically. ### Important notes: - The script automatically refreshes the access token when needed. You don't need to manually update the token for subsequent operations **if using OAuth**. - If you are using the manual token method, you will need to update `YANDEX360_ACCESS_TOKEN` manually due to the limited token lifespan. - Ensure you include the `--dnssleep` option with a value of at least 600 seconds (10 minutes) to account for the slow DNS record propagation on Yandex 360 DNS. - Whenever possible, use the OAuth method as it provides automatic token refresh and a higher level of security. - Yandex 360 Organization ID can be obtained automatically if the "Read organization data" (directory:read_organization) permission is granted. If not, you must export `YANDEX360_ORG_ID` variable manually. - [You can learn more about the Yandex 360 for Business DNS API access procedure here.](https://yandex.ru/dev/api360/doc/concepts/access.html) - [You can learn more about the OAuth device authorization flow here.](https://yandex.ru/dev/id/doc/ru/codes/screen-code-oauth) - [You can learn more about obtaining debug tokens here.](https://yandex.ru/dev/id/doc/ru/tokens/debug-token) - [Report any bugs or issues here.](https://github.com/acmesh-official/acme.sh/issues/5213) ## 168. Use HE DDNS DNS API This uses the Dynamic DNS API in the Hurricane Electric DNS service (https://dns.he.net/). 1. Add new TXT record for `_acme-challenge.example.com` in HE DNS interface, select "Enable entry for dynamic dns" (the content will automatically be like "Acme challenge key", that's fine) 2. Click the "Generate a DDNS key" button in the DDNS column, click the "Generate a key" button in the form, copy the key and Submit the form 3. Set the HE_DDNS_KEY variable: ``` export HE_DDNS_KEY="the_generated_key" ``` To issue a certificate run: ```sh ./acme.sh --issue --dns dns_he_ddns -d example.com ``` The `HE_DDNS_KEY` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/5238) ## 169. Using the IONOS Cloud DNS API For information on how to obtain a token, please read the IONOS Cloud API [documentation](https://docs.ionos.com/reference/readme/get-started#authorization). Please note that [IONOS Cloud DNS](https://docs.ionos.com/cloud/network-services/cloud-dns) API is different from [IONOS Core API](https://github.com/acmesh-official/acme.sh/wiki/dnsapi2#129-using-the-ionos-domain-api) After obtaining token, you need to export it as an environment variable: ``` export IONOS_TOKEN="..." ``` Then, you can issue a certificate by executing: ``` ./acme.sh --issue --dns dns_ionos_cloud -d example.com ``` Please report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/5243) ## 170. Using the Omg.lol DNS API 1. Collect your API Key - Navigate to [https://home.omg.lol/account](https://home.omg.lol/account) - Log in (if not already logged in) - Scroll all the way to the bottom - click the clipboard to copy your API key 2. Export the following variables: ```sh export OMG_ApiKey="your_api_key" # as collected from your accounts page export OMG_Address="your_omg.lol_address" # Leading '@' not required ``` 3. Use the `acme.sh` command with the `--dns dns_omglol` parameter to issue your certificate. For example: ```sh ./acme.sh --issue --dns dns_omglol --dnssleep 120 -d address.omg.lol -d *.address.omg.lol ``` Please report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/5299) ## 171. Use Power-Mailinabox Use the Power-Mail-In-a-Box (PMIAB) Custom DNS REST API interface to PMIAB DNS. You only need to set your PMIAB login credentials and the fully qualified domain name of the PMIAB Server. Suggest single quote over double quote to ensure characters are not interpreted by the shell - important for passwords. ```sh export PMIAB_Username='your_PMIAB_admin_username' export PMIAB_Password='your_PMIAB_admin_password' export PMIAB_Server='FQDN_of_your_PMIAB_Server' ``` To issue a cert: ```sh ./acme.sh --issue --dns dns_pmiab -d example.com -d *.example.com ``` The `PMIAB_Username`, `PMIAB_Password` and `PMIAB_Server` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. Please report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/2550) ## 172. Use Technitium DNS Server API If your Domain is hosted on your (own) Technitium DNS Server, then ```sh export Technitium_Server=url.of.your.name.server # like ns1.example.com export Technitium_Token=API_TOKEN ``` Then issue a cert: ```sh ./acme.sh --issue --dns dns_technitium -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/6116) ## 173. Use ZoneEdit DNS API This uses ZoneEdit DNS API for [zoneedit](https://www.zoneedit.com/) dns service. It was developed as a separate project [sslcertzoneedit](https://github.com/blueslow/sslcertzoneedit) with information provided in the [Zoneedit forum](https://forum.zoneedit.com/index.php?threads/automating-changes-of-txt-records-in-dns.7394/post-19772) Before first execution define the following in sh (or bash): ```sh export ZONEEDIT_ID="your id" export ZONEEDIT_Token="Your token" ``` Where ZONEEDIT_ID is your zone edit ID and ZONEEDIT_Token is the same token as for dynamic IP dns update at [zoneedit](https://www.zoneedit.com/). Then issue a cert: ```sh ./acme.sh --issue --dns dns_zoneedit -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/6135) ## 174. Use Anikeen Cloud DNS API This uses Anikeen DNS API for [Anikeen Cloud](https://anikeen.cloud) dns service. For information on how to obtain a token, please read the [Anikeen Cloud API documentation](https://docs.api.anikeen.cloud). After obtaining token, you need to export it as an environment variable: ```sh export ANIKEEN_API_KEY="your_access_token" ``` Then, you can issue a certificate by executing: ```sh ./acme.sh --issue --dns dns_anikeen -d example.com -d *.example.com ``` Please report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/6175) ## 175. Use mijn.host DNS API *(merge request pending)* This script uses DNS API for [mijn.host](https://mijn.host/) dns service and is based on [API documentation](https://mijn.host/api/doc/) Before first execution define the following in sh (or bash): ```sh export MIJN_HOST_API_KEY="your API key" ``` API keys can be generated in mijn.host customer portal [API settings](https://mijn.host/cp/account/api/). Be aware that the maximum lifetime for an API key is 6 months, so you'll need to update it regularly. To issue a cert: ```sh ./acme.sh --issue --dns dns_mijn_host -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/6177) ## 176. Use OpenProvider (REST) DNS API *(merge request pending)* This script uses DNS API for [OpenProvider](https://www.openprovider.com) domain and dns service and is based on their newer REST [API documentation](https://docs.openprovider.com/doc/all). Now allowing usage of a single request validation entry for the DNS API script without the need to do a full DNS zone overlay everytime like in the older XML specifications. Before first execution define the following in sh (or bash): ```sh export OPENPROVIDER_REST_USERNAME="username" export OPENPROVIDER_REST_PASSWORD="password" ``` The API authentication is based on the [OpenProvider control panel](https://cp.openprovider.eu) credentials; * username: API/account username, same as OpenProvider control panel username * password: API/account password, same as OpenProvider control panel username Both `OPENPROVIDER_REST_USERNAME` and `OPENPROVIDER_REST_PASSWORD` will be saved in `~/.acme.sh/account.conf` and will be reused when needed. If there are multiple control panel contacts (like admin/tech/billing) under a reseller account, decide which account/contact you want to use for API connection/integration and use its username and password. You could create a dedicated account for the DNS API scripting to be executed. For more information please use the OpenProvider article [Getting-started-with-Openprovider-API](https://support.openprovider.eu/hc/en-us/articles/360025683173-Getting-started-with-Openprovider-API) To issue a cert: ```sh ./acme.sh --issue --dns dns_openprovider_rest -d example.com -d *.example.com ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/6122) ## 177. Use Beget.com DNS API This uses [Beget.com](https://beget.com/) DNS API. 1. First you need to login to your beget.com acount and enable the API. Go to [this page](https://cp.beget.com/settings/access/api) ("Account settings" -> "Access restriction" -> "Beget API") and turn on "Allow API authentication" switch. 2. Set separate API password. Push `Set a new password for the API` button for that. 3. Set "Allowed methods" checkboxes: - `DNS admnistration` - `Domain administration` - or simply use `All API functions` checkbox Before running acme.sh script you need to provide your login/password: ```sh export Beget_Username="your account login" export Beget_Password="API password" ``` To essue your sertificate run: ```sh ./acme.sh --issue --server letsencrypt --dns dns_beget -d example.com ``` For wildcard certificate use: ```sh ./acme.sh --issue --server letsencrypt --dns dns_beget -d example.com -d '*.example.com' ``` *Note: "ZeroSSL" does not work in some countries, so use "Let's Encrypt" instead.* Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/6200) ## 178. Use FreeMyIP DNS API This uses [FreeMyIP.com](https://freemyip.com) DNS API. 1. First you need to create a new (not already taken) domain 2. Grab the API token you are given > [!CAUTION] > Make sure you save the token somewhere safe, as it is the only authentication to you domain registration Before running `acme.sh` script, you need to provide your token: ```sh export FREEMYIP_Token="API_token" ``` To issue your certificate run: ```sh ./acme.sh --issue --dns dns_freemyip -d example.freemyip.com ``` > [!NOTE] > FreeMyIP does not support setting multiple TXT record for the same subdomain. > Apply for a certificate one domain at a time Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/6247) ## 179. Use area-7 DNS API This uses the DNS-API of area-7 IT-Services GmbH Cloud-DNS 1. First you need to create a new (not already taken) domain 2. Grab the API token you are given Before running `acme.sh` script, you need to provide your token: ```sh export area7_Token="API_token" ``` To issue your certificate run: ```sh ./acme.sh --issue --dns dns_area7 -d example.area-7.cloud ``` Report any bugs or issues [here](https://github.com/acmesh-official/acme.sh/issues/6248) ## 180. Use HestiaCP DNS API API Key Setup: 1. Log in to HestiaCP panel as admin or as normal user 2. Go to Server -> Configure -> API if admin, or click on your profile and click Access Keys above "Edit user" form. 3. Generate a key pair with "update-dns-records" permission 4. Copy Host, Access Key, and Secret Key 5. Login to our HestiaCP server as root, and go to /usr/local/hestia/data/api 6. The file "update-dns-records" should contain this line in order for this script to work: ROLE='user' COMMANDS='v-list-dns-records,v-change-dns-record,v-delete-dns-record,v-add-dns-record' By default, only v-list-dns-records and v-change-dns-record are enabled which is not enough for this script to work. NOTES: - for wildcard certificates to work, you need to use LetsEncrypt V2 provider, not Alpha ZeroSSL which is default in acme.sh - You will be able to request SSL certs with this script only for domains that are defined under your user for which you've created the access key/secret key Example Usage: ```sh export HESTIA_HOST="https://panel.domain.com:8083" export HESTIA_ACCESS="your_access_key" export HESTIA_SECRET="your_secret_key" export HESTIA_USER="your_username" acme.sh --issue -d example.com -d *.example.com --dns dns_hestiacp ``` ## 181. Use Netim DNS API You need a reseller account to access the DNS API. API Key Setup: 1. Log in to Netim Direct with a reseller account 2. Go to Account -> Personal information and find your "UserID:" 3. Use the same pasword used to login on Netim Direct Before running `acme.sh` script, you need to provide your user and secret: ```sh export NETIM_USER='XX1234' export NETIM_SECRET='mypassword' ``` To issue your certificate run: ```sh ./acme.sh --issue --dns dns_netim -d example.domain.com ``` Report bugs at https://github.com/acmesh-official/acme.sh/issues/6273 ## 182. Use Spaceship DNS API API Key Setup: 1. **Access Launchpad** Log in to your Spaceship account → Navigate to **Launchpad** from the dashboard. 2. **Go to API Manager** In Launchpad → Click on **API Manager**. 3. **Enable API Access** In API Manager → Ensure **API Access** is set to **Enable** (toggle if needed). 4. **Create New API Key** In API Manager → Click **New API Key**. 5. **Configure Custom Access** Select **Custom Access** → Enable only: - **DNS Records - Read** - **DNS Records - Write** Disable all other permissions. 6. **Create the API Key** Click **Create API Key** → Copy and store the secret securely (it won’t be shown again). Before running `acme.sh` script, you need to provide your user and secret: ```sh export SPACESHIP_API_KEY='8azEY0VMllj859ZqepH7' export SPACESHIP_API_SECRET='JkZcYYVvSgwSAOXugXrBZ38nbhcanwiZvYP1MtTu0erI32Vmdxtcxn0tTGGL7SGW' export SPACESHIP_ROOT_DOMAIN='(Optional) ' ``` To issue your certificate run: ```sh ./acme.sh --issue --dns dns_spaceship -d example.domain.com ``` Report bugs at https://github.com/acmesh-official/acme.sh/issues/6304 ## 183. Use Edgecenter DNS API This uses [Edgecenter](https://edgecenter.ru/) DNS API. API Key Setup: 1. Log in to your Edgecenter account → Click on the gear icon in the upper left corner of the page → Click on **API tokens**. 2. Click on **Create token**. 3. In the “Name” field, specify the token name. 4. (optional) In the “Description” field, you can enter additional information about the token. 5. In the **Role** section, specify the rights that will be assigned to the created token. 6. In the **Expiration** section, select the expiration date of the token: - “Never expire” — sets the token's validity period to unlimited. - “Set expiration date” — sets the expiration date of the token in the field below. 7. Click the **Create** button to generate the API token. A pop-up window with the API token will be opened. 8. After you save the generated token, click **OK, I've copied token**. You can view the information about the token in the **API tokens** section. Before running `acme.sh` script, you need to provide your secret: ```sh export EDGECENTER_API_KEY='YOUR_API_TOKEN' ``` To issue your certificate run: ```sh ./acme.sh --issue --server letsencrypt --dns dns_edgecenter -d example.com ``` Report bugs at https://github.com/acmesh-official/acme.sh/issues/6313 ## Use custom API If your API is not supported yet, you can write your own DNS API. Let's assume you want to name it `myapi`: 1. Create a bash script named `~/.acme.sh/dns_myapi.sh`, 2. In the script you must have a function named `dns_myapi_add()` which will be called by acme.sh to add the DNS records. 3. Then you can use your API to issue cert like this: ```sh ./acme.sh --issue --dns dns_myapi -d example.com -d *.example.com ``` For more details, please check our sample script: [dns_myapi.sh](https://github.com/acmesh-official/acme.sh/blob/master/dnsapi/dns_myapi.sh) See: [DNS API Dev Guide](https://github.com/acmesh-official/acme.sh/wiki/DNS-API-Dev-Guide) ## Use lexicon DNS API [How to use lexicon DNS API](https://github.com/acmesh-official/acme.sh/wiki/How-to-use-lexicon-DNS-API) ----------------------------------- **More APIs coming soon...** acme.sh-0.0~git20250417.7502af3/dnscheck.md000066400000000000000000000005441500024665000175110ustar00rootroot00000000000000In dns mode, after the dns record is added, acme.sh will use cloudflare public dns or google dns to check if the record has taken effect. If you don't want this check, please use `--dnssleep 300`. ``` acme.sh --issue -d xxxxx --dns dns_xxx --dnssleep 300 ``` Then acme.sh will wait for `300` seconds instead of checking through the public dns. acme.sh-0.0~git20250417.7502af3/dnssleep.md000066400000000000000000000007021500024665000175400ustar00rootroot00000000000000 In dns mode, after the dns record is added, acme.sh will use cloudflare public dns or google dns to check if the record has taken effect. If you don't want this check, please use `--dnssleep 300`. acme.sh --issue -d xxxxx --dns dns_xxx --dnssleep 300 Then acme.sh will wait for 300 seconds instead of checking through the public dns. The parameter is stored in `~/.acme.sh//.conf` using the variable Le_DNSSleep='###' acme.sh-0.0~git20250417.7502af3/how-about-the-private-key-access-modes,--chmod,-or-chown-or-umask.md000066400000000000000000000026451500024665000320030ustar00rootroot00000000000000# How acme.sh deals with the private key file modes? A short answer is: **we deal with the file permission as little as possible.** A longer answer is: **we almost don't change the file permissions, you set it yourself, and it will be kept forever.** Ok, let me give a longer answer: 1. By default, the key/cert files are saved in `~/.acme.sh`, this folder is set to mode `700` by default. So, nobody else can read your private key. 2. When you use `--install-cert` command to **copy** the cert to the target locations, we use `cat keyfile > target_key_file` pattern, in which the target file permission is not changed, and you only need **write** permission to the target file. Yes, if the target file doesn't exist for the first time, it will be created with your default *umask*, which is **umask 022** in most of the unix/linux systems. In this case, somebody else *may* read your private key file. But you can change the file mode manually, `chmod 600 target_key_file`. *The reasons why we don't change the file mode are:* 1. We respect the users choice most. We trust you more than ourselves. you can change the file modes manually, you know your system best. We respect your choice. 2. We can not use `umask` also. In webroot mode, we have to create validation file, if umask is set to `022`, the webserver would not be able to read the validation file. So, doing more doesn't mean doing better. Less is more. acme.sh-0.0~git20250417.7502af3/ipcert.md000066400000000000000000000004251500024665000172130ustar00rootroot00000000000000Just use the ip address as the `-d` parameter: ``` acme.sh --issue -d 1.1.1.1 -w /etc/apache/xxxxxx ``` As the rfc 8738 requires: https://tools.ietf.org/html/rfc8738 The ip address can not be validated by dns methods. Only http/webroot and alpn methods are allowed. acme.sh-0.0~git20250417.7502af3/notify.md000066400000000000000000000646421500024665000172500ustar00rootroot00000000000000# Set notifications acme.sh can send notifications in its cronjob. Every night when the renew cronjob runs, you may receive notifications based on `notify-level` and `notify-mode`. To configure notifications, use the `--set-notify` argument. This will send test notifications and update account.conf with the new settings. ``` --notify-level 0|1|2|3 Set the notification level: Default value is 2. 0: disabled, no notification will be sent. 1: send notification only when there is an error. No news is good news. 2: send notification when a cert is successfully renewed, or there is an error 3: send notification when a cert is skipped, renewed, or error. You will receive notification every night with this level. --notify-mode 0|1 Set notification mode. Default value is 0. 0: Bulk mode. Send all the domain's notifications in one message(email) 1: Cert mode. Send a message for every single cert. You may receive a bulk of emails in one night. --notify-hook [hookname] Set the notify hook --notify-source Set the server name in the notification message ``` The notifications can be emails or any other supported ways, such as requesting to a webhook, etc. You can also implement your own hook. See example: `mailgun.sh` or `sendgrid.sh` ## Usage: ```sh acme.sh --set-notify [--notify-hook mailgun] acme.sh --set-notify [--notify-level 2] acme.sh --set-notify [--notify-mode 0] acme.sh --set-notify [--notify-source myservername ] ``` There can be multiple `--notify-hook` parameters: ``` acme.sh --set-notify --notify-hook mailgun --notify-hook mail ``` And, all the parameters can be used together: ```sh acme.sh --set-notify --notify-hook mailgun --notify-hook mail \ --notify-level 2 \ --notify-mode 0 ``` ## 1. Set notification for mailgun.com Send notification by mailgun.com api. The notification email will be sent to your email address. Please register a free account at mailgun.com, you will get your api key. If you don't have a domain, you can use the sandbox domain in your account. It looks like `sandbox888888.mailgun.org`. If you use the sandbox domain, you must add your receiving email address as an "Authorized recipient" https://app.mailgun.com/app/account/authorized ```sh #The api key in your account. export MAILGUN_API_KEY="xxxxxxxx" #The api domain, you can use the sandbox domain in your account. export MAILGUN_API_DOMAIN="xxxxxx.com" #Optional, the mail from address. it must be user@MAILGUN_API_DOMAIN export MAILGUN_FROM="xxx@xxxxxx.com" #The mail to address, which is to receive the notification. export MAILGUN_TO="yyyy@gmail.com" #Optional, if your mailgun account is in eu region, you must set MAILGUN_REGION export MAILGUN_REGION="us|eu" #optional, use "us" as default acme.sh --set-notify --notify-hook mailgun ``` ## 2. Set notification for sendgrid.com ```sh export SENDGRID_API_KEY="xxxxxxxxxx" export SENDGRID_FROM="xxxx@cccc.com" export SENDGRID_TO="xxxx@xxx.com" export SENDGRID_FROM_NAME="Email Sender Name" # Custom name other than the email FROM address configured above. acme.sh --set-notify --notify-hook sendgrid ``` ## 3. Set notification for mail Set it in your systems environment: ```sh export MAIL_FROM="xxx@xxx.com" # or "Xxx Xxx ", currently works only with sendmail export MAIL_TO="xxx@xxx.com" # your account e-mail will be used as default if available ``` It will try to find and use `sendmail`, `ssmtp`, `mutt`, `mail` or `msmtp` automatically, if installed. (If you don't have any of these, you may be able to use [smtp notifications](#12-set-notification-for-smtp) instead.) If you want to specify which application to use, please use `MAIL_BIN`: ```sh export MAIL_BIN="sendmail" # should be one of following: sendmail, ssmtp, mutt, mail or msmtp (with or without path) ``` Use the given account instead of the account named "default" in `msmtp` command. ```sh export MAIL_MSMTP_ACCOUNT="account" ``` Ok, let's set notification hook: ```sh acme.sh --set-notify --notify-hook mail ``` The `MAIL_BIN`, `MAIL_TO` and `MAIL_FROM` will be saved in ~/.acme.sh/account.conf and will be reused when needed. ## 4. Set notification for Slack Webhooks First get your [Slack Webhook URL](https://slack.com/apps/A0F7XDUAZ-incoming-webhooks), then set it in your systems environment: ```sh export SLACK_WEBHOOK_URL="..." export SLACK_CHANNEL="..." # overwrites Slack Webhook channel export SLACK_USERNAME="..." # overwrites Slack Webhook username ``` Ok, let's set notification hook: ``` acme.sh --set-notify --notify-hook slack ``` The `SLACK_WEBHOOK_URL`, `SLACK_CHANNEL` and `SLACK_USERNAME` will be saved in ~/.acme.sh/account.conf and will be reused when needed. ## 5. Set notification for Slack App Create [a Slack app](https://api.slack.com/apps) and allow the app to send messages by granting the `chat:write` permission. Once the app was allowed to send messages you need to install the app into your workspace. Slack channel and the App token can be configured via the following environement variables: ```sh export SLACK_APP_CHANNEL="..." export SLACK_APP_TOKEN="xoxb-..." ``` Once the requried parameters have been configured you can setup the notification hook via the following command: ``` acme.sh --set-notify --notify-hook slack_app ``` The `SLACK_APP_CHANNEL` and `SLACK_APP_TOKEN` will be saved in ~/.acme.sh/account.conf and will be reused when needed. ## 6. Set notification for postmarkapp.com Send notification by postmarkapp.com API. The notification email will be sent to your email address. First get your [token](https://account.postmarkapp.com), then set it in your systems environment: ```sh #The api token. export POSTMARK_TOKEN="xxxxxxxx" #The mail to address. export POSTMARK_TO="xxx@xxx.com" #The mail from address. export POSTMARK_FROM="xxx@xxx.com" ``` Ok, let's set notification hook: ```sh acme.sh --set-notify --notify-hook postmark ``` The `POSTMARK_TOKEN`, `POSTMARK_TO` and `POSTMARK_FROM` will be saved in ~/.acme.sh/account.conf and will be reused when needed. If there are any bugs for postmarkapp.com API, please report here: https://github.com/Neilpang/acme.sh/issues/2309 ## 7. Set notification for pushover.net Send notification via pushover.net's api. The notification will be pushed to the specified pushover application. Make a note of your PushOver user key from your account dashboard Create your pushover application at https://pushover.net/apps/build and note the API Token. ```sh #The application token. export PUSHOVER_TOKEN="xxxxxxxx" #Your User key. export PUSHOVER_USER="xxxxxxxx" #Optional, name of a custom sound listed at https://pushover.net/api#sounds (Blank or not set will play default) export PUSHOVER_SOUND="xxxxxxxx" #Optional, name of a registered pushover client device, names are available on your dashboard. Default = "" (all devices) export PUSHOVER_DEVICE="xxxxxxxx" #Optional, Priority level of notification, Lowest Priority (-2), Low Priority (-1), Normal Priority (0), High Priority (1). Default=Normal Priority export PUSHOVER_SOUND="x" ``` Ok, let's set notification hook: ```sh acme.sh --set-notify --notify-hook pushover ``` The PUSHOVER_TOKEN, PUSHOVER_USER and PUSHOVER_SOUND will be saved in ~/.acme.sh/account.conf and will be reused when needed. If there are any bugs for pushover.net notify, please report here: https://github.com/Neilpang/acme.sh/issues/2329 ## 8. Set notification for IFTTT Webhooks Send notification via IFTTT Webhooks so that you can make acme.sh work with tons of [IFTTT](https://ifttt.com) services. Firstly, connect our IFTTT to Webhooks service at [https://ifttt.com/maker_webhooks](https://ifttt.com/maker_webhooks) and click "Documentation" in the top right corner to get the API key. Secondly, create our IFTTT applet with Webhooks as `this' and whatever as `that', we'll setup the event name(e.g. acme_status) for this applet trigger. Now we can set acme.sh notification hook: ```sh #The API key. export IFTTT_API_KEY="xxxx" #Our event name, this should be same as the setting of your applet. export IFTTT_EVENT_NAME="acme_status" #Optional: the key of notification subject, available values are "value1", "value2", "value3", default "value1" export IFTTT_SUBJECT_KEY="value1" #Optional: the key of notification content, available values are "value1", "value2", "value3", default "value2" export IFTTT_CONTENT_KEY="value2" #Now we're ready to set notify hook acme.sh --set-notify --notify-hook ifttt ``` The `IFTTT_API_KEY`, `IFTTT_EVENT_NAME`, `IFTTT_SUBJECT_KEY` and `IFTTT_CONTENT_KEY` will be saved in ~/.acme.sh/account.conf and will be reused when needed. If there are any bugs for IFTTT Webhooks notify, please report here: https://github.com/Neilpang/acme.sh/issues/2421 ## 9. Set notification for xmpp (aka jabber) Install `sendxmpp` manually or using your distributions package manager. Configure the sending account in `~/.sendxmpprc` e.g.: ```sh username: example jserver: example.com password: xxxxxxxx ``` Set it in your systems environment: ```sh export XMPP_TO="xxx@xxx.com" # the xmpp account to send notifications to ``` Currently only `sendxmpp` is supported for sending notifications but support for similar tools can be added easily. If you want to specify which application to use, please use `XMPP_BIN`: ```sh export XMPP_BIN="/usr/bin/sendxmpp" # optional: override command to send xmpp messages export XMPP_BIN_ARGS="--tls-ca-path=/etc/ssl/certs'" # optional: arguments for the xmpp command ``` Ok, let's set notification hook: ```sh acme.sh --set-notify --notify-hook xmpp ``` The `XMPP_TO`, `XMPP_BIN` and `XMPP_BIN_ARGS` will be saved in ~/.acme.sh/account.conf and will be reused when needed. On debian based systems `sendxmpp` has problems validating certificates (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854210). ## 10. Set notification for dingtalk.com(钉钉) Push notification to dingtalk group by group robot webhook api. First create a group robot, get your webhook url, and set a keyword. 推送通知到钉钉群聊天机器人. 先在群设置中添加一个 webhook 机器人. 获得 webhook url. 并设置一个 keyword. 目前不支持签名模式. https://ding-doc.dingtalk.com/doc#/serverapi2/qf2nxq ```sh export DINGTALK_WEBHOOK='https://oapi.dingtalk.com/robot/send?access_token=b05ccexxxxx' export DINGTALK_KEYWORD=acme acme.sh --set-notify --notify-hook dingtalk ``` ## 11. Set notification for QQ with self-built CQHTTP API ### 中文说明 通过 CoolQ 的插件 CQHTTP 将消息推送到 QQ。需要您自行部署 CQHTTP 服务端。部署详情参见 [CoolQ 社区](https://cqp.cc)和 [CQHTTP](https://cqhttp.cc) 的文档。 CoolQ 是一个第三方开发的无头 QQ 客户端，并提供了一些插件功能。在开始之前，您需要自行准备一个 QQ 号码作为机器人，并保证您的 QQ 和机器人 QQ 是好友关系以便发送通知。CQHTTP 是 CoolQ 的一个插件，为 CoolQ 提供了 HTTP API。 这个 hook 有四个环境变量可供传入: - `CQHTTP_TOKEN`: 建议非空，将 CQHTTP 配置文件中您设置的 Access Token 填入。 - `CQHTTP_USER`: 必需，接收推送通知的 QQ 号码。您需要自行保证机器人号码可以向接收者的 QQ 号码发送消息。 - `CQHTTP_APIROOT`: 必需，您搭建的 CQHTTP 服务器的 URL (不包含斜杠结尾)。 - `CQHTTP_CUSTOM_MSGHEAD`: 可选，自定义的消息开头。默认值是 "A message from acme.sh:". ### English version Push notifications to QQ via the plugin CQHTTP of CoolQ. A self-built CQHTTP server is needed. Visit [the community of CoolQ](https://cqp.cc) and [the docs of CQHTTP](https://cqhttp.cc) for the details of deployment. CoolQ is a third-party headless QQ client, which provides a strong plugin system. Before we start, you need to prepare a QQ number for the robot. And ensure that your QQ number is a friend of the robot. CQHTTP is a plugin of CoolQ, which provides HTTP API for CoolQ. This hook can parse four environment variables: - `CQHTTP_TOKEN`: Recommend to be not empty, QQ application token, which is set in CQHTTP server. - `CQHTTP_USER`: Required, QQ receiver ID. Make sure that the sender has right permission to send message to the receiver. - `CQHTTP_APIROOT`: Required, CQHTTP Server URL (without slash suffix) - `CQHTTP_CUSTOM_MSGHEAD`: Optional, custom message header. Default value is "A message from acme.sh:". ### Demo ```sh export CQHTTP_TOKEN="Itsjustat0ken,qwq" # That's the access token export CQHTTP_USER="10086" # That's your QQ number (receiver) export CQHTTP_APIROOT="http://cqhttp-server.local:5700" # That's your server address acme.sh --set-notify --notify-hook cqhttp ``` After that, you'll receive a message (在这之后，你将收到一条信息如下): ```plain A message from acme.sh: Hello, this is a notification from acme.sh If you receive this message, your notification works. ``` ## 11. Set notification for Microsoft Teams First get your [Microsoft Teams Webhook URL](https://docs.microsoft.com/en-us/microsoftteams/platform/concepts/connectors/connectors-using#setting-up-a-custom-incoming-webhook), then set it in your systems environment: ```sh export TEAMS_WEBHOOK_URL="" export TEAMS_THEME_COLOR="586069" export TEAMS_SUCCESS_COLOR="2cbe4e" export TEAMS_ERROR_COLOR="cb2431" export TEAMS_SKIP_COLOR="586069" ``` Ok, let's set notification hook: ``` acme.sh --set-notify --notify-hook teams ``` The `TEAMS_WEBHOOK_URL`, `TEAMS_THEME_COLOR`, `TEAMS_SUCCESS_COLOR`, `TEAMS_ERROR_COLOR` and `TEAMS_SKIP_COLOR` will be saved in ~/.acme.sh/account.conf and will be reused when needed. To omit default color set variable value to any non xdigit character, eg. `TEAMS_SUCCESS_COLOR="-"`. ## 12. Set notification for SMTP acme.sh can send email notifications by connecting directly to an SMTP mail server. Most commercial email service providers (ESPs) and corporate email systems support sending through SMTP, including Amazon SES, GSuite/Google Workspaces, Outlook.com, and others. SMTP notification is available in acme.sh v2.8.9 or later. Please report bugs in the SMTP notify hook in [issue #3358](https://github.com/acmesh-official/acme.sh/issues/3358). SMTP notifications in acme.sh require Python 3.4 or later, Python 2.7, or curl on the machine where you run acme.sh. (If you don't have Python or curl, you may be able to use [mail notifications](#3-set-notification-for-mail) instead.) First, get the SMTP connection information for your mail server or service. You'll need to know: * the SMTP hostname (e.g., smtp.example.com) and port if non-standard (e.g., 587) * type of secure connection required: "tls" (called _STARTTLS_ or _explicit TLS_), "ssl" (called _TLS wrapper_ or _implicit TLS_), or "none" * whether authentication (login) is required, and if so the username and password to use Set in your system environment: ```sh # These are required: export SMTP_FROM="from@example.com" # just the email address (no display names) export SMTP_TO="to@example.com,to2@example.net" # just the email address, use commas between multiple emails export SMTP_HOST="smtp.example.com" export SMTP_SECURE="tls" # one of "none", "ssl" (implicit TLS, TLS Wrapper), "tls" (explicit TLS, STARTTLS) # The default port depends on SMTP_SECURE: none=25, ssl=465, tls=587. # If your SMTP server uses a different port, set it: export SMTP_PORT="2525" # If your SMTP server requires AUTH (login), set: export SMTP_USERNAME="" export SMTP_PASSWORD="" # acme.sh will try to use the python3, python2.7, or curl found on the PATH. # If it can't find one, or to run a specific command, set: export SMTP_BIN="/path/to/python_or_curl" # If your SMTP server is very slow to respond, you may need to set: export SMTP_TIMEOUT="30" # seconds for SMTP operations to timeout, default 30 ``` Ok, let's set notification hook: ```sh acme.sh --set-notify --notify-hook smtp ``` If everything works, you will see a "success" message and receive a test email at the `SMTP_TO` address. If you get an error message, it should explain what went wrong somewhere. The exact problem may be mixed in with less helpful error codes, so read through the message carefully. For additional troubleshooting, run the command again with `--debug` or `--debug 2`. (At debug level 2 or higher the output will show the complete SMTP session transcript, which may include the SMTP password.) All of the `SMTP_*` settings will be saved in ~/.acme.sh/account.conf and will be reused when needed. ## 13. Set notification for Telegram To have notifications delivered via Telegram, you first need to [create a new Telegram bot](https://core.telegram.org/bots#creating-a-new-bot), by talking to [@BotFather](https://t.me/botfather) within your Telegram client. Save the bot token that is returned after creation. Next, you need the `chat_id` of your Telegram account (or a group). The simplest way to do this is to start a conversation with your new bot, and send a simple test message to it. Then, using `curl`, fetch the [`getUpdates`](https://core.telegram.org/bots/api#getupdates) API endpoint, and look for the chat id in the json object for the message you sent. For example: ```sh $ bot_token="...." # enter your new bot's API token here. $ curl -s "https://api.telegram.org/bot${bot_token}/getUpdates" | python -mjson.tool { "ok": true, "result": [ { "message": { "chat": { "first_name": "Joe", "id": 12345678, <----- This is the Chat ID. "last_name": "Bloggs", "type": "private", "username": "joebloggs" }, ...... "text": "text of the test message you sent", ...... $ ``` Once you have both the API token, and the chat ID for where you want the Bot to set notifications, set the following two variables to be used by the notification hook script: ```sh export TELEGRAM_BOT_APITOKEN="..." # Token returned by @BotFather during bot creation above. export TELEGRAM_BOT_CHATID="..." # Chat ID fetched above. #For China users only: 如果无法访问 telgram 的api 服务器, 可以设置自己的代理 export TELEGRAM_BOT_URLBASE="https://tgproxy.example.com" # Your own proxy address, it can be cloudflare or other ``` And then set notification hook: ``` acme.sh --set-notify --notify-hook telegram ``` ## 14. Set notification for pushbullet.com Send notification via pushbullet.com's api. The notification will be pushed to the specified pushover application. Create a Pushbullet API key at https://www.pushbullet.com/#settings/account. If you want to send the push notification to a specific device, follow the instructions at https://docs.pushbullet.com/#list-pushes to get a list of all your devices, you should make note of the device `iden` field. ```sh #Required, the application token. export PUSHBULLET_TOKEN="xxxxxxxx" #Optional, Id of the specific device you want to send the notification export PUSHBULLET_DEVICE="xxxxxxxx" ``` Ok, let's set notification hook: ```sh acme.sh --set-notify --notify-hook pushbullet ``` The PUSHBULLET_TOKEN and PUSHBULLET_DEVICE will be saved in ~/.acme.sh/account.conf and will be reused when needed. ## 15. Set notification for feishu.cn(飞书) Send notification to feishu group via webhook api. First create a group robot, get your webhook url, and set a keyword. 推送通知到飞书群聊天机器人。先在群设置中添加一个群机器人，获得 webhook 地址，并设置一个关键字（目前暂不支持签名模式）。 API说明：https://open.feishu.cn/document/ukTMukTMukTM/ucTM5YjL3ETO24yNxkjN ```sh export FEISHU_WEBHOOK='https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxxxxxxxxx' export FEISHU_KEYWORD=acme acme.sh --set-notify --notify-hook feishu ``` ## 16. Set notification for iOS Bark Send notification via Bark's API. The notification will be pushed to the specified pushover application. Download Bark from [App Store](https://apps.apple.com/cn/app/bark-%E7%BB%99%E4%BD%A0%E7%9A%84%E6%89%8B%E6%9C%BA%E5%8F%91%E6%8E%A8%E9%80%81/id1403753865). Open the app and get the API URL. It usually starts with "https://api.day.app/" and is followed by a UUID of length 22. Set `BARK_API_URL` to the complete URL, which is in the format of "https://api.day.app/XXXXXXXXXXXXXXXXXXXXXX". You can also use your API server. Please refer to . You **NEED** to set `BARK_API_URL`, every other parameter is optional. For convenience, `BARK_GROUP` will be automatically set to "ACME" if not set. For a more detailed description of each parameter, refer to the docs of the [Bark API v2](https://github.com/Finb/bark-server/blob/master/docs/API_V2.md#push). ```bash export BARK_API_URL="https://api.day.app/XXXXXXXXXXXXXXXXXXXXXX" export BARK_GROUP="ACME" export BARK_SOUND="alarm" export BARK_LEVEL="active" export BARK_BADGE=0 export BARK_AUTOMATICALLYCOPY="1" export BARK_COPY="My clipboard Content" export BARK_ICON="https://example.com/icon.png" export BARK_ISARCHIVE="1" export BARK_URL="https://example.com" acme.sh --set-notify --notify-hook bark ``` ## 17. Set notification for Gotify 通过gotify推送通知 其中`GOTIFY_PRIORITY`的数字是0-9（等级越高，推送级别越高） Send notifications through gotify The number of 'GOTIFYBRIORITY' is 0-9 (the higher the level, the higher the push level) ``` export GOTIFY_URL="https://example.com" export GOTIFY_TOKEN="XXXXXXX" export GOTIFY_PRIORITY="0" ``` ```sh acme.sh --set-notify --notify-hook gotify ``` ## 18. Set notification for work.weixin.qq.com(企业微信) Send notification to workwx group via webhook api. First create a group robot, get your webhook url, and set a keyword. 推送通知到企业微信群聊天机器人。先在群设置中添加一个群机器人，获得 webhook 地址，并设置一个关键字（目前暂不支持签名模式）。 API说明：https://developer.work.weixin.qq.com/document/path/91770 ```sh export WEIXIN_WORK_WEBHOOK='https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=693a91f6-7xxx-4bc4-97a0-0ec2sifa5aaa' export WEIXIN_WORK_KEYWORD=acme acme.sh --set-notify --notify-hook weixin_work ``` ## 19. Set notification for Discord Webhooks First, get your [Discord Webhook URL](https://support.discord.com/hc/en-us/articles/228383668-Intro-to-Webhooks), then set it in your systems environment: ```sh export DISCORD_WEBHOOK_URL="..." export DISCORD_AVATAR_URL="..." # if empty, defaults to the defined avatar export DISCORD_USERNAME="..." # if empty, defaults to the defined username ``` Ok, let's set the notification hook: ``` acme.sh --set-notify --notify-hook discord ``` The `DISCORD_WEBHOOK_URL`, `DISCORD_AVATAR_URL`, and `DISCORD_USERNAME` will be saved in ~/.acme.sh/account.conf and will be reused when needed. ## 20. Set notification for Whatsapp by CallmeBot First, get your [CallmeBot Webhook URL](https://www.callmebot.com/blog/free-api-whatsapp-messages/), then set it in your systems environment: ```sh export CALLMEBOT_YOUR_PHONE_NO="..." # your phone no export CALLMEBOT_API_KEY="..." ``` Ok, let's set the notification hook: ``` acme.sh --set-notify --notify-hook callmebotWhatsApp ``` The `CALLMEBOT_YOUR_PHONE_NO` and `CALLMEBOT_API_KEY` will be saved in ~/.acme.sh/account.conf and will be reused when needed. ## 21. Set notification for customscript Notify via a custom shell script. The script is called with the following three parameters: 1. Subject 2. Message 3. Status code (0: success, 1: error 2: skipped) To set the notification hook: ```sh export CUSTOMSCRIPT_PATH="/usr/local/bin/acme-notification.sh" acme.sh --set-notify --notify-hook customscript ``` The CUSTOMSCRIPT_PATH will be saved in ~/.acme.sh/account.conf and will be reused when needed. Template for a custom script: ```sh #!/usr/bin/env sh subject="$1" message="$2" status="$3" do-something "$subject ($status): $message" ``` ## 22. Set-notification-for-Gchat-channel-or-contact First, you have determine what the "webhook" URL is for the channel or contact you'd like to notify. In the desktop app, the "manage webhooks" option in somewhat hidden under the "heading" for the channel or contact. Select the channel/contact and look in the middle of the page for a left arrow, the name, and a down arrow. Click on the down arrow, select "manage webhooks" and copy the URL to the clipboard. Here are the step to configure Gchat notify: `export SAVED_GCHAT_WEBHOOK_URL='paste your webbook url here'` `acme.sh --set-notify --notify-hook gchat` ## 23. Set notification for AWS SES (API) Uses AWS SES API (rather than SMTP credentials). You'll need to setup a API user with the following security permissions to send email. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "ses:SendEmail", "ses:SendRawEmail", "ses:SendBulkEmail" ], "Resource": "*" } ] } ``` Usage: ```sh export AWS_ACCESS_KEY_ID="sdfsdfsdfljlbjkljlkjsdfoiwje" export AWS_SECRET_ACCESS_KEY="xxxxxxxxxxxxxx" # Use the REGION column from the table # https://docs.aws.amazon.com/general/latest/gr/ses.html export AWS_SES_REGION="xx-xxxx-x" export AWS_SES_TO="xxx@xxx.xxx" export AWS_SES_FROM="xxx@xxx.xxx" # Custom name other than the email FROM address configured above (optional). export AWS_SES_FROM_NAME="Something" acme.sh --set-notify --notify-hook aws_ses ``` ## 24. Set notification for Mattermost Bot First, create a bot account on your Mattermost https://developers.mattermost.com/integrate/reference/bot-accounts/. Don't forget save bot's Access Token. Then set the environment variables. API "/posts" URL (current at https://api.mattermost.com/): ```sh export MATTERMOST_API_URL=https://you_mattermost_server/api/v4/posts ``` Channel ID for notifications. Find the Channel ID in the Web Interface or Desktop Application by click View Info button. ```sh export MATTERMOST_CHANNEL_ID=z1y2x3w4v5u6t7s8r1q2p3o4n5 ``` Bot Token: ```sh export MATTERMOST_BOT_TOKEN=a1b2c3d4e5f6g7h8i1j2k3l4m5 ``` and finally turn on acme.sh notifications: ```sh acme.sh --set-notify --notify-hook mattermost ``` ## 25. Set notification for ntfy Make sure to change `NTFY_TOPIC` to something that cannot be guessed easily. `NTFY_TOKEN` is optional. ```sh export NTFY_URL="https://ntfy.sh" export NTFY_TOPIC="xxxxxxxxxxxxx" export NTFY_TOKEN="xxxxxxxxxxxxx" acme.sh --set-notify --notify-hook ntfy ``` acme.sh-0.0~git20250417.7502af3/openvpn2.4.7服务端和客户端使用注意.md000066400000000000000000000003001500024665000336660ustar00rootroot00000000000000 如果使用官方默认证书链或者CA，openvpn将不能工作，请看[这里](https://github.com/acmesh-official/acme.sh/issues/4100)，包括问题所在，排查思路和解决方法acme.sh-0.0~git20250417.7502af3/revokecert.md000066400000000000000000000012351500024665000200760ustar00rootroot00000000000000# How to revoke a cert. ``` acme.sh --revoke -d example.com ``` You can also specify a reason for revocation: ``` acme.sh --revoke -d example.com --revoke-reason 0 ``` The valid reasons are `0-10`, See: https://tools.ietf.org/html/rfc5280#section-5.3.1 ``` unspecified (0), keyCompromise (1), cACompromise (2), affiliationChanged (3), superseded (4), cessationOfOperation (5), certificateHold (6), -- value 7 is not used removeFromCRL (8), privilegeWithdrawn (9), aACompromise (10 ``` acme.sh-0.0~git20250417.7502af3/sudo.md000066400000000000000000000072311500024665000167010ustar00rootroot00000000000000[TODO] Do not use `sudo` if you cannot properly configure it. **Notice:** This wiki is not complete yet. Using `sudo` is not recommended. If not properly configured to not ask for password it may cause permission issues when running commands from the cronjob (like renew), resulting in some or all of your certificates not being renewed and eventually will expire. If you need root, please `su` to root first, and then install acme.sh and use it. ```sh #uninstall for current user acme.sh --uninstall #change to root sudo su #install again for root user curl https://get.acme.sh | sh -s email=my@example.com #use it bash acme.sh --issue -d ..... ``` Now, if you are completely sure of the issues and the possibilities with the usage of `sudo` and still want to use it, you can pass the `--force` parameter to work with sudo. # Process YMMV based on Linux distribution and method of installing acme.sh ## create non-root account For this example, we use "acme" but you can use whatever you'd like. ``` sudo useradd -d /etc/acme-sh/ -s /sbin/nologin -c "acme-sh service account" acme sudo chown acme:mail /etc/acme-sh/ ``` ## define crontab for non-root account ``` sudo su - -s /bin/bash acme crontab -e ``` Adjust path to your acme.sh installation script, insert into your non-root crontab ``` 12 0 * * * /usr/share/acme.sh/acme.sh --cron --home "/etc/acme-sh" > /dev/null ``` ## Webserver issue method When using the webserver method, you need to define the directories acme.sh writes to and adjust ownership to our non-root account. While monitoring the issue event logs, you might observer additional file structure permission errors when ran as non-root. From our experiences, those can be ignored as the script does not hard fail as the important directories and files creation is functional. Maybe this is where the --force should be used? ``` sudo mkdir -p /var/www/EXAMPLE.COM/htdocs/.well-known/acme-challenge sudo chown acme:acme /var/www/EXAMPLE.com/htdocs/.well-known/acme-challenge ``` ## nginx config You probably already have a web daemon configuration file for your application. If you are running a mail server, you need a basic http port 80 server for acme.sh ``` sudo $EDITOR /etc/nginx/conf.d/example.com.conf ``` ``` server { listen [::]:80; listen 80; server_name EXAMPLE.COM; access_log /var/log/nginx/EXAMPLE.COM.access_log main; error_log /var/log/nginx/EXAMPLE.COM.error_log info; root /var/www/EXAMPLE.COM/htdocs; } ``` ## Register and Issue There are more detailed instructions within the documentation and wiki for this process. This is a brief example. ``` acme.sh --register-account -m admin@example.com acme.sh --debug --issue -d mail.example.com -d foo.example.com -d -d bar.example.com -w /var/www/EXAMPLE.COM/htdocs ``` ## visudo This grants our non-root service account super user rights to restart services during certificate renewals. ``` sudo visudo ```` Insert this line, adjust to your deployment use-cases and sudo version ``` acme ALL=(ALL:ALL) NOPASSWD: /etc/init.d/postfix restart, /etc/init.d/dovecot restart ``` ## Install Create a new directory which our non-root account can write certificates into. ``` sudo mkdir /etc/ssl/acme sudo chown acme:acme /etc/ssl/acme ``` These restart commands should match what you defined in visudo above ``` acme.sh --installcert -d mail.example.com --keypath /etc/ssl/acme/example.com.key --capath /etc/ssl/acme/example.com.ca --fullchainpath /etc/ssl/acme/example.com.crt --reloadcmd "sudo /etc/init.d/postfix restart && sudo /etc/init.d/dovecot restart" ``` ## cleanup (optional) Your distro might place a global bashrc script. This is not needed. ``` sudo rm /etc/bash/bashrc.d/acme.sh ``` acme.sh-0.0~git20250417.7502af3/tlsa-next-key.md000066400000000000000000000003621500024665000204320ustar00rootroot00000000000000TODO: You can use `--force-new-domain-key` option to make acme.sh generate a new key when renewing a cert everytime. There will be a "$Le_Next_Domain_Key" (`~/.acme.sh/domain.com/domain.key.next"`) key file generate for use next time. acme.sh-0.0~git20250417.7502af3/如何安装.md000066400000000000000000000050741500024665000221700ustar00rootroot00000000000000生成免费SSL证书前，请使用Linux/BSD系统更新工具更新CA包和系统补丁，以避免在生成证书过程中出现未预料到的问题。完成更新后，可以按照以下步骤进行安装。 ### 步骤1: 安装 acme.sh #### 在线安装方式：https://get.acme.sh 使用 `curl` 安装： ```bash curl https://get.acme.sh | sh -s email=my@example.com ``` 或者使用 `wget` 安装： ```bash wget -O - https://get.acme.sh | sh -s email=my@example.com ``` #### 使用 GitHub 安装： 使用`curl`安装： ```bash curl https://raw.githubusercontent.com/acmesh-official/acme.sh/master/acme.sh | sh -s -- --install-online -m my@example.com ``` 或者使用`wget`安装： ```bash wget -O - https://raw.githubusercontent.com/acmesh-official/acme.sh/master/acme.sh | sh -s -- --install-online -m my@example.com ``` ### 步骤2: 使用 git 克隆并安装 ```bash git clone --depth 1 https://github.com/acmesh-official/acme.sh.git cd acme.sh ./acme.sh --install -m my@example.com ``` ### 步骤3: 高级安装选项 ```bash git clone --depth 1 https://github.com/acmesh-official/acme.sh.git cd acme.sh ./acme.sh --install \ --home ~/myacme \ --config-home ~/myacme/data \ --cert-home ~/mycerts \ --accountemail "my@example.com" \ --accountkey ~/myaccount.key \ --accountconf ~/myaccount.conf \ --useragent "this is my client." ``` 你不需要设置所有选项，只需设置你关心的那些选项即可。这些选项的详细说明如下： - `--home` 是安装 `acme.sh` 的自定义目录，默认安装在 `~/.acme.sh` 中。 - `--config-home` 是一个可写文件夹，`acme.sh` 将所有文件（包括证书/密钥、配置文件）写入其中，默认为 `--home` 中。 - `--cert-home` 是用于保存你发行的证书的自定义目录，默认保存在 `--config-home` 中。 - `--accountemail` 是用于注册到 Let's Encrypt 的电子邮件地址，你将在此处接收到更新通知邮件。 - `--accountkey` 是保存你的账户私钥的文件。默认保存在 `--config-home` 中。 - `--useragent` 是发送给 Let's Encrypt 的用户代理标头值。 - `--nocron` 安装 `acme.sh` 时不安装 cron 作业。 ### 特殊情况: 从 certbot 转换 LE 账户数据到 acme.sh 如果已经使用 certbot，并希望转换其 LE 账户数据到 acme.sh 格式，请参考以下链接进行转换：https://github.com/maddes-b/linux-stuff/tree/main/acme.sh 。 如果要重新使用从 certbot 创建的 LE 账户，请在安装过程中**不要**指定 `-m/--email`。 以上是安装和配置 acme.sh 以生成免费SSL证书的详细步骤和说明。acme.sh-0.0~git20250417.7502af3/说明.md000066400000000000000000000236621500024665000201430ustar00rootroot00000000000000**acme.sh** 实现了 `acme` 协议，可以从 `ZeroSSL`，`Let's Encrypt` 等 CA 生成免费的证书。 主要步骤: 1. 安装 **acme.sh** 2. 生成证书 3. 安装证书到 `Nginx/Apache` 或者其他服务 4. 更新证书 5. 更新 **acme.sh** 6. 出错怎么办，如何调试 下面详细介绍. # 1. 安装 acme.sh 安装很简单，一条命令: ```shell curl https://get.acme.sh | sh -s email=my@example.com ``` 或者 ```shell wget -O - https://get.acme.sh | sh -s email=my@example.com ``` 普通用户和 root 用户都可以安装使用。 安装过程进行了以下几步: 1) 把 acme.sh 安装到你的 **home** 目录下: ```shell ~/.acme.sh/ ``` 并创建 一个 shell 的 alias，例如 `.bashrc`，方便你的使用: `alias acme.sh=~/.acme.sh/acme.sh` 2) 自动为你创建 cronjob， 每天 0:00 点自动检测所有的证书，如果快过期了，需要更新，则会自动更新证书。 更高级的安装选项请参考: https://github.com/acmesh-official/acme.sh/wiki/How-to-install **安装过程不会污染已有的系统任何功能和文件**，所有的修改都限制在安装目录中: `~/.acme.sh/` **注意**：如果安装完成后提示 `-bash: acme.sh: command not found`，需要手动执行 `source ~/.bashrc` # 2. 生成证书 **acme.sh** 实现了 **acme** 协议支持的所有验证协议。 一般有两种方式验证: HTTP 和 DNS 验证。 ## HTTP 验证 ### 直接签发 只需要指定域名，并指定域名所在的网站根目录. **acme.sh** 会全自动的生成验证文件，并放到网站的根目录，验证完成后会聪明的删除验证文件，整个过程没有任何副作用。 ```shell acme.sh --issue -d mydomain.com -d www.mydomain.com --webroot /home/wwwroot/mydomain.com/ ``` ### 使用 Apache 模式 如果你用的 **Apache** 服务器，**acme.sh** 还可以智能的从 **Apache** 的配置中自动完成验证，你不需要指定网站根目录: ```shell acme.sh --issue --apache -d example.com -d www.example.com -d cp.example.com ``` ### 使用 Nginx 模式 如果你用的 **Nginx** 服务器，或者反代，**acme.sh** 还可以智能的从 **Nginx** 的配置中自动完成验证，你不需要指定网站根目录: ```shell acme.sh --issue --nginx -d example.com -d www.example.com -d cp.example.com ``` **注意，无论是 Apache 还是 Nginx 模式，acme.sh 在完成验证之后，会恢复到之前的状态，都不会私自更改程序本身的配置. 好处是你不用担心配置被搞坏，也有一个缺点，你需要自己配置 SSL 项，否则只能成功生成证书，你的网站还是无法正常使用 HTTPS。** ### 使用独立服务模式 如果服务器上没有运行任何 Web 服务，**80** 端口是空闲的，那么 **acme.sh** 还能假装自己是一个 WebServer，临时监听 **80** 端口，完成验证: ```shell acme.sh --issue --standalone -d example.com -d www.example.com -d cp.example.com ``` ### 修改默认 CA acme.sh 脚本默认 CA 服务器是 `ZeroSSL`，有时可能会导致获取证书的时候一直出现：`Pending，The CA is processing your order，please just wait.` 只需要把 CA 服务器改成 `Let's Encrypt` 即可，虽然更改以后还是有概率出现 pending，但基本 2-3 次即可成功 ``` acme.sh --set-default-ca --server letsencrypt ``` 更高级的用法请参考: https://github.com/acmesh-official/acme.sh/wiki/How-to-issue-a-cert ## DNS 验证 如果你没有服务器，没有公网 IP，只需要 DNS 的解析记录即可完成验证。 ### 手动验证 这需要你手动在域名上添加一条 TXT 解析记录，验证域名所有权。 注意，如果使用手动验证，acme.sh 将无法自动更新证书，每次都需要手动添加解析来验证域名所有权。**如果有自动更新证书的需求，请使用自动验证（DNS API）。** ```shell acme.sh --issue --dns -d example.com -d www.example.com -d cp.example.com ``` 然后，**acme.sh** 会生成相应的解析记录显示出来，你只需要在你的域名管理面板中添加这条 TXT 记录即可。 等待解析完成之后，执行以下命令重新生成证书： ``` shell acme.sh --renew -d mydomain.com ``` 注意这里现在用的是 `--renew` 参数 ### 自动验证（DNS API） DNS 方式的真正强大之处在于可以使用域名解析商提供的 API 自动添加 TXT 记录，且在完成验证后删除对应的记录。 **acme.sh** 目前支持超过一百家的 DNS API。 以 DNSPod.cn 为例，你需要先登录到 [DNSPod.cn](https://dnspod.cn/)，拿到你的 DNSPod API Key 和 ID 并设置： ```shell export DP_Id="1234" export DP_Key="sADDsdasdgdsf" ``` 现在我们可以签发通配符证书了： ```shell acme.sh --issue --dns dns_dp -d example.com -d *.example.com ``` `DP_Id` 和 `DP_Key` 将保存在 `~/.acme.sh/account.conf` 中，并在需要时自动获取，无需手动再设置。 更详细的 DNS API 用法: https://github.com/acmesh-official/acme.sh/wiki/dnsapi # 3. 复制证书 证书生成好以后，我们需要把证书复制给对应的 Apache、Nginx 或其他服务器去使用。 **必须使用** `--install-cert` 命令来把证书复制到目标文件，请勿直接使用 `~/.acme.sh/` 目录下的证书文件，这里面的文件都是内部使用，而且目录结构将来可能会变化。 ## Apache 示例: ``` acme.sh --install-cert -d example.com \ --cert-file /path/to/certfile/in/apache/cert.pem \ --key-file /path/to/keyfile/in/apache/key.pem \ --fullchain-file /path/to/fullchain/certfile/apache/fullchain.pem \ --reloadcmd "service apache2 force-reload" ``` ## Nginx 示例: ``` acme.sh --install-cert -d example.com \ --key-file /path/to/keyfile/in/nginx/key.pem \ --fullchain-file /path/to/fullchain/nginx/cert.pem \ --reloadcmd "service nginx reload" ``` Nginx 的配置项 `ssl_certificate` 需要使用 `/etc/nginx/ssl/fullchain.cer` ，而非 `/etc/nginx/ssl/.cer` ，否则 [SSL Labs](https://www.ssllabs.com/ssltest/) 的测试会报证书链问题（`Chain issues Incomplete`）。 默认情况下，证书每 60 天更新一次（可自定义）。更新证书后，Apache 或者 Nginx 服务会通过 `reloadcmd` 传递的命令自动重载配置。 注意：`reloadcmd` 非常重要。证书会自动申请续签，但是如果没有正确的 `reloadcmd` 命令，证书可能无法被重新应用到 Apache 或者 Nginx，因为配置没有被重载。 # 4. 查看已安装证书信息 ```shell acme.sh --info -d example.com ``` 会输出如下内容： ``` DOMAIN_CONF=/root/.acme.sh/example.com/example.com.conf Le_Domain=example.com Le_Alt=no Le_Webroot=dns_ali Le_PreHook= Le_PostHook= Le_RenewHook= Le_API=https://acme-v02.api.letsencrypt.org/directory Le_Keylength= Le_OrderFinalize=https://acme-v02.api.letsencrypt.org/acme/finalize/23xxxx150/781xxxx4310 Le_LinkOrder=https://acme-v02.api.letsencrypt.org/acme/order/233xxx150/781xxxx4310 Le_LinkCert=https://acme-v02.api.letsencrypt.org/acme/cert/04cbd28xxxxxx349ecaea8d07 Le_CertCreateTime=1649358725 Le_CertCreateTimeStr=Thu Apr 7 19:12:05 UTC 2022 Le_NextRenewTimeStr=Mon Jun 6 19:12:05 UTC 2022 Le_NextRenewTime=1654456325 Le_RealCertPath= Le_RealCACertPath= Le_RealKeyPath=/etc/acme/example.com/privkey.pem Le_ReloadCmd=service nginx force-reload Le_RealFullChainPath=/etc/acme/example.com/chain.pem ``` # 5. 更新证书 目前证书每 60 天自动更新，你无需任何操作。 但是你也可以强制续签证书： ```shell acme.sh --renew -d example.com --force ``` # 6. 关于修改 `reloadcmd` 目前修改 `reloadcmd` 没有专门的命令，可以通过重新安装证书来实现修改 `reloadcmd` 的目的。 此外，安装证书后，相关信息是保存在 `~/.acme.sh/example.com/example.conf` 文件下的，内容就是 `acme.sh --info -d example.com` 输出的信息，不过 `reloadcmd` 在文件中使用了 Base64 编码。理论上可以通过直接修改该文件来修改 `ReloadCmd`，且修改时，无需 Base64 编码，直接写命令原文 `acme.sh` 也可以识别。 不过，由于 `example.conf` 文件的位置和内容格式以后可能会改变，且 `example.conf` 一直都是内部使用，后续也有可能会改为用 SQLite 或者 MySQL 格式存储. 所以一般不建议自己修改。 # 7. 更新 acme.sh acme.sh 还在不断开发中，因此强烈建议保持并使用最新的版本。 升级 acme.sh 到最新版： ```shell acme.sh --upgrade ``` 如果你不想手动升级，可以开启自动升级: ```shell acme.sh --upgrade --auto-upgrade ``` 之后，acme.sh 就会自动保持更新了。 你也可以随时关闭自动更新: ```shell acme.sh --upgrade --auto-upgrade 0 ``` # 8. 出错怎么办： 如果出错，请添加 `--debug` 参数输出详细的调试信息： ```shell acme.sh --issue ..... --debug ``` 或者输出更详细的信息： ```shell acme.sh --issue ..... --debug 2 ``` 请参考：https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh 在 DNS 验证模式下如果 debug 中出现诸如 `timed out` 等字样可能是因为 `GFW` HTTP(S) Proxy 环境变量。（请按照自己实际设定修改） ```shell export http_proxy="socks5h://localhost:1081" export https_proxy="socks5h://localhost:1081" ``` 如果是使用 docker 则完整示例配置如下： ```shell docker run --rm -it \ -v "/etc/acme":/acme.sh \ -e "CF_Token=[填入自己的信息]" \ -e "CF_Account_ID=[填入自己的信息]" \ -e "CF_Zone_ID=[填入自己的信息]" \ -e http_proxy="socks5h://[代理A]:1234" \ -e https_proxy="socks5h://[代理A]:1234" \ --network container:[代理A]\ neilpang/acme.sh \ --issue -d example.com --dns dns_cf --debug ``` 上述例子中使用 Cloudflare 的 DNS 来签发证书，并通过把 acme.sh 链接到容器[代理A]，来转发 curl 请求（请按照自己实际设定修改） 最后，本文并非完全的使用说明，还有很多高级的功能，更高级的用法请参看 wiki 页面：https://github.com/acmesh-official/acme.sh/wiki/