diff --git a/README.md b/README.md index 110615e..4866dfc 100644 --- a/README.md +++ b/README.md @@ -251,6 +251,30 @@ return greenlock.renew({}).then(function(results) { +
+Greenlock#remove({ subject }) + +## Greenlock#manager.remove() + +To stop certificates from being renewed, you must remove them. + +If you are implementing your own `manager` callbacks, I recommend that you mark them as deleted +(i.e. `deleted_at` in your database) rather than actually removing them. Just in case. + +```js +gl.remove({ + subject: 'example.com' +}).then(function(siteConfig) { + // save the old site config elsewhere, just in case you need it again +}); +``` + +| Parameter | Description | +| --------- | ------------------------------------------------------ | +| subject | the first domain on, and identifier of the certificate | + +
+
-[Custom SSL Cert & Domain Management](https://git.rootprojects.org/root/greenlock-manager-test.js) +Custom SSL Cert & Domain Management -# SSL Certificate & Domain Management +## SSL Certificate & Domain Management Full Docs: https://git.rootprojects.org/root/greenlock-manager-test.js @@ -361,22 +385,22 @@ In many cases it will interact with the same database as the Key & Cert Store, a
-[Custom Key & Cert Storage](https://git.rootprojects.org/root/greenlock-store-test.js) +Custom Key & Cert Storage -# Key and Certificate Store +## Key and Certificate Store Full Docs: https://git.rootprojects.org/root/greenlock-store-test.js This set of callbacks update your service with new certificates and keypairs. -Account Keys (JWK) +### Account Keys (JWK) (though typically you only have one account key - because you only have one subscriber email) - accounts.setKeypair({ email, keypair }) - accounts.checkKeypair({ email }) -Certificate Keys (JWK + PEM) +### Certificate Keys (JWK + PEM) (typically you have one for each set of domains, and each load balancer) @@ -384,7 +408,7 @@ Certificate Keys (JWK + PEM) - certificates.checkKeypair({ subject }) (these are fine to implement the same as above, swapping subject/email) -Certificate PEMs +### Certificate PEMs - certificates.set({ subject, pems }) - certificates.check({ subject }) @@ -392,9 +416,9 @@ Certificate PEMs
-[Custom ACME HTTP-01 Challenges](https://git.rootprojects.org/root/acme-http-01-test.js) +Custom ACME HTTP-01 Challenges -# ACME Challenge HTTP-01 Strategies +## ACME Challenge HTTP-01 Strategies Full Docs: https://git.rootprojects.org/root/acme-http-01-test.js @@ -417,9 +441,9 @@ TODO: getAcmeHttp01Challenge
-[Custom ACME DNS-01 Challenges](https://git.rootprojects.org/root/acme-dns-01-test.js) +Custom ACME DNS-01 Challenges -# ACME Challenge DNS-01 Strategies +## ACME Challenge DNS-01 Strategies Full Docs https://git.rootprojects.org/root/acme-dns-01-test.js @@ -440,12 +464,13 @@ each domain before authorizing a certificate.
Notes on HTTP-01 & DNS-01 Integrations -# Notes on HTTP-01 & DNS-01 Integrations + +## Notes on HTTP-01 & DNS-01 Integrations For Public Web Servers running on a VPS, the **default HTTP-01 challenge plugin** -will work just fine for most people. +will work just fine, for most people. -However, for +However, for environments that cannot be verified via public HTTP, such as - **Wildcard Certificates** - **IoT Environments** @@ -453,9 +478,10 @@ However, for - **Private Networks** Greenlock provides an easy way to integrate Let's Encrypt with your existing services -through a variety of **DNS-01** infrastructure +through a variety of **DNS-01** challenges. + +### Why not use dns01 for everything? -Why Typically file propagation is faster and more reliably than DNS propagation. Therefore, http-01 will be preferred to dns-01 except when wildcards or **private domains** are in use.