diff options
Diffstat (limited to 'docs/reference/plugins/validation')
17 files changed, 0 insertions, 355 deletions
diff --git a/docs/reference/plugins/validation/dns/acme-dns.md b/docs/reference/plugins/validation/dns/acme-dns.md deleted file mode 100644 index 18f7f6a..0000000 --- a/docs/reference/plugins/validation/dns/acme-dns.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -sidebar: reference ---- - -# acme-dns -Use an [acme-dns](https://github.com/joohoi/acme-dns) server to handle the validation records. -The plugin will ask you to choose an endpoint to use. For testing the `https://auth.acme-dns.io/` -endpoint is useful, but it is a security concern. As the readme of that project clearly states: - -> "You are encouraged to run your own acme-dns instance." - -It's possible to use basic authentication for your acme-dns service by specifying a url with -the format `https://user:password@acme-dns.example.com/` - -## Unattended -Not supported, unless there is a pre-existing acme-dns registration for all the domains. -The reason for this is that acme-dns requires you to create CNAME records. In the future this -might be scripted the same way we can script DNS validation itself, but so far there hasn't been -enough demand for that feature to make it worth developing.
\ No newline at end of file diff --git a/docs/reference/plugins/validation/dns/azure.md b/docs/reference/plugins/validation/dns/azure.md deleted file mode 100644 index 6518557..0000000 --- a/docs/reference/plugins/validation/dns/azure.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -sidebar: reference ---- - -# Azure DNS -Create the record in Azure DNS. - -{% include plugin-seperate.md %} - -## Setup -This assumes you already have your DNS managed in Azure; if not, you'll need to set that up first. If you are -using the Azure DNS option for validation, you'll need to get certain info from your Azure Tenant, and create -a service principal for win-acme to use (you'll only need to create on of these - it's basically an account that has authority to create DNS records). -There are two ways to authenticate with Azure: - -#### Create Azure AD Service Principal Account -Use the [Azure CLI](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-windows?view=azure-cli-latest) -to create an [Azure service principal](https://docs.microsoft.com/en-us/cli/azure/create-an-azure-service-principal-azure-cli?view=azure-cli-latest) - -You then need to give this Service Principal access to change DNS entries. In the Azure Portal: -* Go to `DNS Zones` > `sub.example.com` > `Access Control (IAM)` -* Click `Add` -* For Role, choose `DNS Zone Contributor` -* Assign access to `Azure AD user, group, or application` -* Select your Service Principal -* Click `Save` - -#### Use a Managed Service Identity -More information [here](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview) - -### Configuring the plugin -During setup of the validation the program will ask several questions. -Here is to answer them with information from the Azure Portal. - -* `DNS Subscription ID`: DNS Zones > `sub.example.com` > `Subscription ID` -* `DNS Resource Group Name`: DNS zones > `sub.example.com` > `Resource Group`) - -Only when authenticating Service Principal Account: - -* `Directory/tenant id`: Azure Active Directory > Properties > `Directory ID`. -* `Application client id`: Azure Active Directory > App registrations > [Service Principal] > `Application ID`. -* `Application client secret`: The password that was generated when you created the Service Principal Account. - -### Resources -- [How to: Use Azure PowerShell to create a service principal with a certificate](https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-authenticate-service-principal-powershell) -- [DNS SDK](https://docs.microsoft.com/en-us/azure/dns/dns-sdk) - -## Unattended -#### Service Principal Account -`--validationmode dns-01 --validation azure --azuretenantid x --azureclientid x --azuresecret *** --azuresubscriptionid x --azureresourcegroupname x` -#### Managaged Resource Identity -`--validationmode dns-01 --validation azure --azureusemsi --azuresubscriptionid x --azureresourcegroupname x`
\ No newline at end of file diff --git a/docs/reference/plugins/validation/dns/cloudflare.md b/docs/reference/plugins/validation/dns/cloudflare.md deleted file mode 100644 index 7c934d9..0000000 --- a/docs/reference/plugins/validation/dns/cloudflare.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -sidebar: reference ---- - -# Cloudflare -Create the record in Cloudflare DNS. - -{% include plugin-seperate.md %} - -## Setup -This assumes you already have your DNS managed in Cloudflare; if not, you'll need to set that up first. If you are -using the Cloudflare DNS option for validation, you'll need to obtain a Cloudflare API Token (not Key) that is allowed -to read and write the DNS records of the zone your domain belongs to. - -### Create an appropriate API Token -1. Navigate here: https://dash.cloudflare.com/profile/api-tokens -2. Click *Create Token* -3. Choose a name -4. Under *Permissions*, select "Zone", "DNS", "Edit"; Click *Add More*, select "Zone", "Zone", "Read" -5. Under *Zone Resources*, select "Include", "All zones" (or "All zones from an account" and select the relevant account). - * Note that restricting access to the single target zone does not work, as we can not get the zone's id by its domain name then. You might be able to exclude other zones specifically. If this is a show stopper for you please open an issue to discuss how to proceed. -6. Finish creating the token, store it in a safe place or, better, paste it directly into win-acme. - -## Unattended -`--validationmode dns-01 --validation cloudflare --cloudflareapitoken ***` diff --git a/docs/reference/plugins/validation/dns/dreamhost.md b/docs/reference/plugins/validation/dns/dreamhost.md deleted file mode 100644 index 22c73be..0000000 --- a/docs/reference/plugins/validation/dns/dreamhost.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -sidebar: reference ---- - -# Dreamhost -Update record for [Dreamhost](https://www.dreamhost.com/) - -{% include plugin-seperate.md %} - -## Setup -Requires an API key - -## Unattended -`--validation dreamhost --validationmode dns-01 --apikey x`
\ No newline at end of file diff --git a/docs/reference/plugins/validation/dns/index.md b/docs/reference/plugins/validation/dns/index.md deleted file mode 100644 index 84251f5..0000000 --- a/docs/reference/plugins/validation/dns/index.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -sidebar: reference ---- - -# DNS validation -DNS validation works as follows: -- For each domain, e.g. `sub.example.com`, the ACME server provides a -challenge consisting of an `x` and `y` value. The truth is actually a little -more complicated than that, but for the sake of this explanation it will suffice. -- The client has to make sure that when the ACME server requests the TXT -records for `_acme-challenge.sub.example.com`, -there should be at least one record called `x` with content `"y"`. -- There may be more than one validation lookup for the same token, e.g. from -different locations or different protocols (IPv4/IPv6). -- Let's Encrypt validates the DNSSEC chain. -- Let's Encrypt follows CNAME records and respects delegated autority. -- Let's Encrypt does *not* disclose the source locations of these lookups, which -effectively means that the DNS records have to be public, at least for the duration of -the validation.
\ No newline at end of file diff --git a/docs/reference/plugins/validation/dns/manual.md b/docs/reference/plugins/validation/dns/manual.md deleted file mode 100644 index 2ab0dcd..0000000 --- a/docs/reference/plugins/validation/dns/manual.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -sidebar: reference ---- - -# Manual -The client will show the record that is supposed to be created on screen and it will have -to be created manually by whatever means necessary. Obviously not good for unattended operation -but it is a good way to get started as a proof of concept, before investing in further -automation. - -## Unattended -Not supported (obviously)
\ No newline at end of file diff --git a/docs/reference/plugins/validation/dns/route53.md b/docs/reference/plugins/validation/dns/route53.md deleted file mode 100644 index ba59836..0000000 --- a/docs/reference/plugins/validation/dns/route53.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -sidebar: reference ---- - -# Route 53 -Create the record in Amazon Route53 - -{% include plugin-seperate.md %} - -## Setup -This requires either a user or an IAM role with the following permissions on the zone: -`route53:GetChange`, `route53:ListHostedZones` and `route53:ChangeResourceRecordSets` - -## Unattended -- User: -`--validation route53 --validationmode dns-01 --route53accesskeyid x --route53secretaccesskey ***` -- IAM role: -`--validation route53 --validationmode dns-01 --route53iamrole x`
\ No newline at end of file diff --git a/docs/reference/plugins/validation/dns/script.md b/docs/reference/plugins/validation/dns/script.md deleted file mode 100644 index 467fb49..0000000 --- a/docs/reference/plugins/validation/dns/script.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -sidebar: reference ---- - -# Script -Run an external script or program to create or update the validation records. - -## Create -A script to create the DNS record must be provided. The arguments passed to the -script will be `create {Identifier} {RecordName} {Token}` by default, where the -following replacements are made by win-acme: - -| Value | Replaced with | -|----------------|----------------| -| `{Identifier}` | host name that's being validated, e.g. `sub.example.com` | -| `{RecordName}` | full name of the TXT record that is being expected, e.g. `_acme-challenge.sub.example.com` | -| `{Token}` | content of the TXT record, e.g. `DGyRejmCefe7v4NfDGDKfA` | - -The order and format of arguments may be customized by providing a diffent argument string. -For example if your script needs arguments like: - -`--host _acme-challenge.example.com --token DGyRejmCefe7v4NfDGDKfA` - -...your argument string should like like this: - -`--host {RecordName} --token {Token}` - -## Delete -Optionally, another script may be provided to delete the record after validation. The arguments passed to the -script will be `delete {Identifier} {RecordName} {Token}` by default. The order and format of arguments may be -customized by providing a diffent argument string, just like for the create script. You can also choose to use -the same script for create and delete, with each their own argument string. - -## Resources -A lot of good example scripts are available from the -[POSH-ACME](https://github.com/rmbolger/Posh-ACME/tree/master/Posh-ACME/DnsPlugins) -project. - -## Unattended -- ##### Create script only -`-validationmode dns-01 --validation script --dnscreatescript c:\create.ps1 [--dnscreatescriptarguments {args}]` -- ##### Create and delete scripts seperate -`-validationmode dns-01 --validation script --dnscreatescript c:\create.ps1 --dnsdeletescript c:\delete.ps1 [--dnscreatescriptarguments {args}] [--dnsdeletescriptarguments {args}]` -- ##### Create-delete script (integrated) -`-validationmode dns-01 --validation script --dnsscript c:\create-and-delete.ps1 [--dnscreatescriptarguments {args}] [--dnsdeletescriptarguments {args}]`
\ No newline at end of file diff --git a/docs/reference/plugins/validation/http/filesystem.md b/docs/reference/plugins/validation/http/filesystem.md deleted file mode 100644 index 4ae8996..0000000 --- a/docs/reference/plugins/validation/http/filesystem.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -sidebar: reference ---- - -# Filesystem -This plugin saves the validation challenge to a local path, which may of course also be a network path. - -{% include validation-http-common.md %} - -## Unattended -`--validation filesystem [--validationsiteid x] [--webroot c:\httpdocs\]`
\ No newline at end of file diff --git a/docs/reference/plugins/validation/http/ftps.md b/docs/reference/plugins/validation/http/ftps.md deleted file mode 100644 index 01369a4..0000000 --- a/docs/reference/plugins/validation/http/ftps.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -sidebar: reference ---- - -# FTP(S) -This plugin uploads the validation challenge to a (secure) FTP server. - -{% include validation-http-common.md %} - -## Unattended -`--validation ftp --webroot ftps://x/ --username admin --password ******`
\ No newline at end of file diff --git a/docs/reference/plugins/validation/http/index.md b/docs/reference/plugins/validation/http/index.md deleted file mode 100644 index 25c8164..0000000 --- a/docs/reference/plugins/validation/http/index.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -sidebar: reference ---- - -# HTTP validation -HTTP validation works as follows: -- For each domain (e.g. `sub.example.com`), the ACME server sends a -challenge consisting of an `x` and `y` value. The truth is actually a little -more complicated than that, but for the sake of this explanation it will suffice. -- The client has to make sure that when the ACME server makes a request -to `http://sub.example.com/.well-known/acme-challenge/x`, the content of the HTTP -response will be `y` with some specific headers set as well. -- The validation request is *always* made to port 80, that cannot be changed. -- The ACME server **does** follow 301/302 redirects. -- There may be more than one validation request for the same token, e.g. from -different locations or different protocols (IPv4/IPv6). -- Let's Encrypt does **not** disclose the source locations of these requests, which -effectively means that the domain has to be accessible for the public, -at least for the duration of the validation.
\ No newline at end of file diff --git a/docs/reference/plugins/validation/http/selfhosting.md b/docs/reference/plugins/validation/http/selfhosting.md deleted file mode 100644 index a1b4c31..0000000 --- a/docs/reference/plugins/validation/http/selfhosting.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -sidebar: reference ---- - -# Self-hosting -This plugin launches a temporary built-in web listener that stores the validation -response in memory. It can share port 80 with IIS and other (Microsoft) software -so this doesn't interfere with regular traffic. Not all software supports this -port sharing feature though. If you get errors telling you that the listener -cannot be started, try to (temporarely) shut down other processes using the -port, or look for another validation method. - -## Non-default port -Even though Let's Encrypt will always send validation requests to port 80, -you may internally proxy, NAT or redirect that to another port. Using the -`--validationport` switch you can tell the plugin to listen to a specific port. - -## Firewall exemption -Obviously, whichever port is used will have to be accessible from outside, meaning -your firewall(s) will have to permit access. Unfortunately due to the use of the -port sharing mechanism, it's not possible to configure the Windows Firewall with -a rule for a specific application (i.e. `wacs.exe`), so you will have to open the -port to `System`. If you feel that is too generous, you could automate enabling/ -disabling this rule by running a script before and after `wacs.exe`. Make sure to -also add that script as steps in the scheduled task. - -## Unattended -`[--validation selfhosting] [--validationport 8080]`
\ No newline at end of file diff --git a/docs/reference/plugins/validation/http/sftp.md b/docs/reference/plugins/validation/http/sftp.md deleted file mode 100644 index 62d59cc..0000000 --- a/docs/reference/plugins/validation/http/sftp.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -sidebar: reference ---- - -# SFTP -This plugin uploads the validation challenge to a SSH FTP, also known as SFTP, server. - -{% include validation-http-common.md %} - -## Unattended -`--validation sftp --webroot ftps://x/ --username admin --password ******`
\ No newline at end of file diff --git a/docs/reference/plugins/validation/http/webdav.md b/docs/reference/plugins/validation/http/webdav.md deleted file mode 100644 index 94bfeaf..0000000 --- a/docs/reference/plugins/validation/http/webdav.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -sidebar: reference ---- - -# SFTP -This plugin pushes the validation challenge to a WebDav path. - -{% include validation-http-common.md %} - -## Unattended -`--validation webdav --webroot ftps://x/ --username admin --password ******`
\ No newline at end of file diff --git a/docs/reference/plugins/validation/index.md b/docs/reference/plugins/validation/index.md deleted file mode 100644 index bfb133d..0000000 --- a/docs/reference/plugins/validation/index.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -sidebar: reference ---- - -# Validation plugins - -A validation plugin is responsible for providing the ACME server with proof that you own the identifiers -(host names) that you want to create a certificate for. The -[ACMEv2 protocol](https://tools.ietf.org/html/draft-ietf-acme-acme-18) defines different -challenge types, three of which are supported by win-acme, namely -[HTTP-01](/win-acme/reference/plugins/validation/http/), -[DNS-01](/win-acme/reference/plugins/validation/dns/) and -[TLS-ALPN-01](/win-acme/reference/plugins/validation/tls-alpn/). - -For wildcard identifiers, only DNS-01 validation is accepted by Let's Encrypt. - -Several other challenge types are not supported for various reasons: -- `TLS-SNI-01/-02` - deprecated and removed -- `PROOFOFPOSSESSION-01` - unknown - -## Default - -By default, the [self-hosting plugin](/win-acme/reference/plugins/validation/http/selfhosting) is used.
\ No newline at end of file diff --git a/docs/reference/plugins/validation/tls-alpn/index.md b/docs/reference/plugins/validation/tls-alpn/index.md deleted file mode 100644 index d1b6aa9..0000000 --- a/docs/reference/plugins/validation/tls-alpn/index.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -sidebar: reference ---- - -# TLS-ALPN validation -TLS-ALPN validation works as follows: -- For each domain (e.g. `sub.example.com`), the ACME server sends a -challenge consisting of an `x` and `y` value. The truth is actually a little -more complicated than that, but for the sake of this explanation it will suffice. -- The client has to make sure that when the ACME server sets up a TLS connection -to `sub.example.com`, a specifically crafted negotiation response with a -self-signed certificate containing the `y` value as extension is presented. -- The validation request is *always* made to port 443, that cannot be changed. -- There may be more than one validation connection for the same token, e.g. -for different IP addresses (in case of multiple A/AAAA records). -- Let's Encrypt does **not** disclose the source locations of these requests, which -effectively means that the domain has to be accessible for the public, -at least for the duration of the validation.
\ No newline at end of file diff --git a/docs/reference/plugins/validation/tls-alpn/selfhosting.md b/docs/reference/plugins/validation/tls-alpn/selfhosting.md deleted file mode 100644 index 836c591..0000000 --- a/docs/reference/plugins/validation/tls-alpn/selfhosting.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -sidebar: reference ---- - -# Self-hosting -This plugin launches a temporary built-in TCP listener that stores the -validation response in memory. There for share port 80 with IIS and -other (Microsoft) software so this doesn't interfere with regular traffic. -Not all software supports this port sharing feature though. If you get errors -telling you that the listener cannot be started, please look for another -validation method. - -## Non-default port -Even though Let's Encrypt will always try to open the validation connection -on port 443, you may internally NAT that to another port. Using the -`--validationport` switch you can tell the plugin to listen to a specific port. - -## Unattended -`--validationmode tls-alpn-01 --validation selfhosting [--validationport 4330]`
\ No newline at end of file |