# community.crypto.acme_certificate_order_create module – Create an ACME v2 order — Community.Crypto Collection documentation

# community.crypto.acme_certificate_order_create module – Create an ACME v2 order

Note

This module is part of the community.crypto collection (version 2.21.0).

It is not included in `ansible-core`. To check whether it is installed, run `ansible-galaxy collection list`.

To install it, use: `ansible-galaxy collection install community.crypto`. You need further requirements to be able to use this module, see Requirements for details.

To use it in a playbook, specify: `community.crypto.acme_certificate_order_create`.

New in community.crypto 2.21.0

## Synopsis

- Creates an ACME v2 order. This is the first step of obtaining a new certificate with the ACME protocol from a Certificate Authority such as Let’s Encrypt or Buypass. This module does not support ACME v1, the original version of the ACME protocol before standardization.

- The current implementation supports the `http-01`, `dns-01` and `tls-alpn-01` challenges.

- This module needs to be used in conjunction with the community.crypto.acme_certificate_order_validate and. community.crypto.acme_certificate_order_finalize module. An order can be effectively deactivated with the community.crypto.acme_certificate_deactivate_authz module. Note that both modules require the output `order_uri` of this module.

- To create or modify ACME accounts, use the community.crypto.acme_account module. This module will not create or update ACME accounts.

- Between the call of this module and community.crypto.acme_certificate_order_finalize, you have to fulfill the required steps for the chosen challenge by whatever means necessary. For `http-01` that means creating the necessary challenge file on the destination webserver. For `dns-01` the necessary dns record has to be created. For `tls-alpn-01` the necessary certificate has to be created and served. It is not the responsibility of this module to perform these steps.

- For details on how to fulfill these challenges, you might have to read through the main ACME specification and the TLS-ALPN-01 specification. Also, consider the examples provided for this module.

- The module includes support for IP identifiers according to the RFC 8738 ACME extension.

## Requirements

The below requirements are needed on the host that executes this module.

- either openssl or cryptography >= 1.5

- ipaddress

## Parameters

Parameter | Comments
--- | ---

account_key_content

string

Content of the ACME account RSA or Elliptic Curve key.

Mutually exclusive with `account_key_src`.

Required if `account_key_src` is not used.

Warning: the content will be written into a temporary file, which will be deleted by Ansible when the module completes. Since this is an important private key — it can be used to change the account key, or to revoke your certificates without knowing their private keys —, this might not be acceptable.

In case `cryptography` is used, the content is not written into a temporary file. It can still happen that it is written to disk by Ansible in the process of moving the module with its argument to the node where it is executed.

account_key_passphrase string added in community.crypto 1.6.0 | Phassphrase to use to decode the account key. Note: this is not supported by the `openssl` backend, only by the `cryptography` backend.

account_key_src

aliases: account_key

path

Path to a file containing the ACME account RSA or Elliptic Curve key.

Private keys can be created with the community.crypto.openssl_privatekey or community.crypto.openssl_privatekey_pipe modules. If the requisite (cryptography) is not available, keys can also be created directly with the `openssl` command line tool: RSA keys can be created with `openssl genrsa ...`. Elliptic curve keys can be created with `openssl ecparam -genkey ...`. Any other tool creating private keys in PEM format can be used as well.

Mutually exclusive with `account_key_content`.

Required if `account_key_content` is not used.

account_uri string | If specified, assumes that the account URI is as given. If the account key does not match this account, or an account with this URI does not exist, the module fails.

acme_directory

string / required

The ACME directory to use. This is the entry point URL to access the ACME CA server API.

For safety reasons the default is set to the Let’s Encrypt staging server (for the ACME v1 protocol). This will create technically correct, but untrusted certificates.

For Let’s Encrypt, all staging endpoints can be found here: https://letsencrypt.org/docs/staging-environment/. For Buypass, all endpoints can be found here: https://community.buypass.com/t/63d4ay/buypass-go-ssl-endpoints

For Let’s Encrypt, the production directory URL for ACME v2 is https://acme-v02.api.letsencrypt.org/directory.

For Buypass, the production directory URL for ACME v2 and v1 is https://api.buypass.com/acme/directory.

For ZeroSSL, the production directory URL for ACME v2 is https://acme.zerossl.com/v2/DV90.

For Sectigo, the production directory URL for ACME v2 is https://acme-qa.secure.trust-provider.com/v2/DV.

The notes for this module contain a list of ACME services this module has been tested against.

acme_version

integer / required

The ACME version of the endpoint.

Must be `1` for the classic Let’s Encrypt and Buypass ACME endpoints, or `2` for standardized ACME v2 endpoints.

The value `1` is deprecated since community.crypto 2.0.0 and will be removed from community.crypto 3.0.0.

Choices:

- `1`

- `2`

csr

path

File containing the CSR for the new certificate.

Can be created with community.crypto.openssl_csr.

The CSR may contain multiple Subject Alternate Names, but each one will lead to an individual challenge that must be fulfilled for the CSR to be signed.

Note: the private key used to create the CSR must not be the account key. This is a bad idea from a security point of view, and the CA should not accept the CSR. The ACME server should return an error in this case.

Precisely one of `csr` or `csr_content` must be specified.

csr_content

string

Content of the CSR for the new certificate.

Can be created with community.crypto.openssl_csr_pipe.

The CSR may contain multiple Subject Alternate Names, but each one will lead to an individual challenge that must be fulfilled for the CSR to be signed.

Note: the private key used to create the CSR must not be the account key. This is a bad idea from a security point of view, and the CA should not accept the CSR. The ACME server should return an error in this case.

Precisely one of `csr` or `csr_content` must be specified.

deactivate_authzs

boolean

Deactivate authentication objects (authz) when issuing the certificate failed.

Authentication objects are bound to an account key and remain valid for a certain amount of time, and can be used to issue certificates without having to re-authenticate the domain. This can be a security concern.

Choices:

- `false`

- `true` ← (default)

replace_cert_id

string

If provided, will request the order to replace the certificate identified by this certificate ID according to the ACME ARI draft 3.

This certificate ID must be computed as specified in the ACME ARI draft 3. It is returned as `cert_id` of the community.crypto.acme_certificate_renewal_info module.

ACME servers might refuse to create new orders that indicate to replace a certificate for which an active replacement order already exists. This can happen if this module is used to create an order, and then the playbook/role fails in case the challenges cannot be set up. If the playbook/role does not record the order data to continue with the existing order, but tries to create a new one on the next run, creating the new order might fail. For this reason, this option should only be used if the role/playbook using it keeps track of order data accross restarts, or if it takes care to deactivate orders whose processing is aborted. Orders can be deactivated with the community.crypto.acme_certificate_deactivate_authz module.

request_timeout integer added in community.crypto 2.3.0 | The time Ansible should wait for a response from the ACME API. This timeout is applied to all HTTP(S) requests (HEAD, GET, POST). Default: `10`

select_crypto_backend

string

Determines which crypto backend to use.

The default choice is `auto`, which tries to use `cryptography` if available, and falls back to `openssl`.

If set to `openssl`, will try to use the `openssl` binary.

If set to `cryptography`, will try to use the cryptography library.

Choices:

- `"auto"` ← (default)

- `"cryptography"`

- `"openssl"`

validate_certs

boolean

Whether calls to the ACME directory will validate TLS certificates.

Warning: Should only ever be set to `false` for testing purposes, for example when testing against a local Pebble server.

Choices:

- `false`

- `true` ← (default)

## Attributes

Attribute | Support | Description
--- | --- | ---
action_group | Action groups: community.crypto.acme, acme | Use `group/acme` or `group/community.crypto.acme` in `module_defaults` to set defaults for this module.
check_mode | Support: none | Can run in `check_mode` and return changed status prediction without modifying target.
diff_mode | Support: none | Will return details on what has changed (or possibly needs changing in `check_mode`), when in diff mode.

## Notes

Note

- Although the defaults are chosen so that the module can be used with the Let’s Encrypt CA, the module can in principle be used with any CA providing an ACME endpoint, such as Buypass Go SSL.

- So far, the ACME modules have only been tested by the developers against Let’s Encrypt (staging and production), Buypass (staging and production), ZeroSSL (production), and Pebble testing server. We have got community feedback that they also work with Sectigo ACME Service for InCommon. If you experience problems with another ACME server, please create an issue to help us supporting it. Feedback that an ACME server not mentioned does work is also appreciated.

- If a new enough version of the `cryptography` library is available (see Requirements for details), it will be used instead of the `openssl` binary. This can be explicitly disabled or enabled with the `select_crypto_backend` option. Note that using the `openssl` binary will be slower and less secure, as private key contents always have to be stored on disk (see `account_key_content`).

## See Also

See also

community.crypto.acme_certificate_order_validate

  Validate pending authorizations of an ACME order.

community.crypto.acme_certificate_order_finalize

  Finalize an ACME order after satisfying the challenges.

community.crypto.acme_certificate_order_info

  Obtain information for an ACME order.

community.crypto.acme_certificate_deactivate_authz

  Deactivate all authorizations (authz) of an ACME order, effectively deactivating the order itself.

community.crypto.acme_certificate_renewal_info

  Determine whether a certificate should be renewed.

The Let’s Encrypt documentation

  Documentation for the Let’s Encrypt Certification Authority. Provides useful information for example on rate limits.

Buypass Go SSL

  Documentation for the Buypass Certification Authority. Provides useful information for example on rate limits.

Automatic Certificate Management Environment (ACME)

  The specification of the ACME protocol (RFC 8555).

ACME TLS ALPN Challenge Extension

  The specification of the `tls-alpn-01` challenge (RFC 8737).

community.crypto.acme_challenge_cert_helper

  Helps preparing `tls-alpn-01` challenges.

community.crypto.openssl_privatekey

  Can be used to create private keys (both for certificates and accounts).

community.crypto.openssl_privatekey_pipe

  Can be used to create private keys without writing it to disk (both for certificates and accounts).

community.crypto.openssl_csr

  Can be used to create a Certificate Signing Request (CSR).

community.crypto.openssl_csr_pipe

  Can be used to create a Certificate Signing Request (CSR) without writing it to disk.

community.crypto.acme_account

  Allows to create, modify or delete an ACME account.

community.crypto.acme_inspect

  Allows to debug problems.

## Examples

    ### Example with HTTP-01 challenge ###

    - name: Create a challenge for sample.com using a account key from a variable
      community.crypto.acme_certificate_order_create:
        account_key_content: "{{ account_private_key }}"
        csr: /etc/pki/cert/csr/sample.com.csr
      register: sample_com_challenge

    # Alternative first step:
    - name: Create a challenge for sample.com using a account key from Hashi Vault
      community.crypto.acme_certificate_order_create:
        account_key_content: >-
          {{ lookup('community.hashi_vault.hashi_vault', 'secret=secret/account_private_key:value') }}
        csr: /etc/pki/cert/csr/sample.com.csr
      register: sample_com_challenge

    # Alternative first step:
    - name: Create a challenge for sample.com using a account key file
      community.crypto.acme_certificate_order_create:
        account_key_src: /etc/pki/cert/private/account.key
        csr_content: "{{ lookup('file', '/etc/pki/cert/csr/sample.com.csr') }}"
      register: sample_com_challenge

    # Perform the necessary steps to fulfill the challenge. For example:
    #
    # - name: Copy http-01 challenges
    #   ansible.builtin.copy:
    #     dest: /var/www/{{ item.identifier }}/{{ item.challenges['http-01'].resource }}
    #     content: "{{ item.challenges['http-01'].resource_value }}"
    #   loop: "{{ sample_com_challenge.challenge_data }}"
    #   when: "'http-01' in item.challenges"

    - name: Let the challenge be validated
      community.crypto.acme_certificate_order_validate:
        account_key_src: /etc/pki/cert/private/account.key
        order_uri: "{{ sample_com_challenge.order_uri }}"
        challenge: http-01

    - name: Retrieve the cert and intermediate certificate
      community.crypto.acme_certificate_order_finalize:
        account_key_src: /etc/pki/cert/private/account.key
        csr: /etc/pki/cert/csr/sample.com.csr
        order_uri: "{{ sample_com_challenge.order_uri }}"
        cert_dest: /etc/httpd/ssl/sample.com.crt
        fullchain_dest: /etc/httpd/ssl/sample.com-fullchain.crt
        chain_dest: /etc/httpd/ssl/sample.com-intermediate.crt

    ### Example with DNS challenge against production ACME server ###

    - name: Create a challenge for sample.com using a account key file.
      community.crypto.acme_certificate_order_create:
        acme_directory: https://acme-v01.api.letsencrypt.org/directory
        acme_version: 2
        account_key_src: /etc/pki/cert/private/account.key
        csr: /etc/pki/cert/csr/sample.com.csr
      register: sample_com_challenge

    # Perform the necessary steps to fulfill the challenge. For example:
    #
    # - name: Create DNS records for dns-01 challenges
    #   community.aws.route53:
    #     zone: sample.com
    #     record: "{{ item.key }}"
    #     type: TXT
    #     ttl: 60
    #     state: present
    #     wait: true
    #     # Note: item.value is a list of TXT entries, and route53
    #     # requires every entry to be enclosed in quotes
    #     value: "{{ item.value | map('community.dns.quote_txt', always_quote=true) | list }}"
    #   loop: "{{ sample_com_challenge.challenge_data_dns | dict2items }}"

    - name: Let the challenge be validated
      community.crypto.acme_certificate_order_validate:
        acme_directory: https://acme-v01.api.letsencrypt.org/directory
        acme_version: 2
        account_key_src: /etc/pki/cert/private/account.key
        order_uri: "{{ sample_com_challenge.order_uri }}"
        challenge: dns-01

    - name: Retrieve the cert and intermediate certificate
      community.crypto.acme_certificate_order_finalize:
        acme_directory: https://acme-v01.api.letsencrypt.org/directory
        acme_version: 2
        account_key_src: /etc/pki/cert/private/account.key
        csr: /etc/pki/cert/csr/sample.com.csr
        order_uri: "{{ sample_com_challenge.order_uri }}"
        cert_dest: /etc/httpd/ssl/sample.com.crt
        fullchain_dest: /etc/httpd/ssl/sample.com-fullchain.crt
        chain_dest: /etc/httpd/ssl/sample.com-intermediate.crt

## Return Values

Common return values are documented here, the following are the fields unique to this module:

Key | Description
--- | ---
account_uri string | ACME account URI. Returned: success
challenge_data list / elements=dictionary | For every identifier, provides the challenge information. Only challenges which are not yet valid are returned. Returned: changed
challenges dictionary | Information for different challenge types supported for this identifier. Returned: success
dns-01 dictionary | Information for `dns-01` authorization. A DNS TXT record needs to be created with the record name `challenge_data[].challenges.dns-01.record` and value `challenge_data[].challenges.dns-01.resource_value`. Returned: if the identifier supports `dns-01` authorization
record string | The full DNS record’s name for the challenge. Returned: success Sample: `"_acme-challenge.example.com"`
resource string | Always contains the string `_acme-challenge`. Returned: success Sample: `"_acme-challenge"`
resource_value string | The value the resource has to produce for the validation. Returned: success Sample: `"IlirfxKKXA...17Dt3juxGJ-PCt92wr-oA"`
http-01 dictionary | Information for `http-01` authorization. The server needs to make the path `challenge_data[].challenges.http-01.resource` accessible via HTTP (which might redirect to HTTPS). A `GET` operation to this path needs to provide the value from `challenge_data[].challenges.http-01.resource_value`. Returned: if the identifier supports `http-01` authorization
resource string | The path the value has to be provided under. Returned: success Sample: `".well-known/acme-challenge/evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA"`
resource_value string | The value the resource has to produce for the validation. Returned: success Sample: `"IlirfxKKXA...17Dt3juxGJ-PCt92wr-oA"`

tls-alpn-01

dictionary

Information for `tls-alpn-01` authorization.

A certificate needs to be created for the DNS name `challenge_data[].challenges.tls-alpn-01.resource` with acmeValidation X.509 extension of value `challenge_data[].challenges.tls-alpn-01.resource_value`. This certificate needs to be served when the application-layer protocol `acme-tls/1` is negotiated for a HTTPS connection to port 443 with the SNI extension for the domain name (`challenge_data[].challenges.tls-alpn-01.resource_original`) being validated.

See https://www.rfc-editor.org/rfc/rfc8737.html#section-3 for details.

Returned: if the identifier supports `tls-alpn-01` authorization

resource string | The DNS name for DNS identifiers, and the reverse DNS mapping (RFC1034, RFC3596) for IP addresses. Returned: success Sample: `"example.com"`
resource_original string | The original identifier including type identifier. Returned: success Sample: `"dns:example.com"`

resource_value

string

The value the resource has to produce for the validation.

Note: this return value contains a Base64 encoded version of the correct binary blob which has to be put into the acmeValidation X.509 extension; see https://www.rfc-editor.org/rfc/rfc8737.html#section-3 for details. To do this, you might need the ansible.builtin.b64decode Jinja filter to extract the binary blob from this return value.

Returned: success

Sample: `"AAb="`

identifier string | The identifier for this challenge. Returned: success Sample: `"example.com"`

identifier_type

string

The identifier’s type.

`dns` for DNS names, and `ip` for IP addresses.

Returned: success

Can only return:

- `"dns"`

- `"ip"`

Sample: `"dns"`

challenge_data_dns dictionary | List of TXT values per DNS record for `dns-01` challenges. Only challenges which are not yet valid are returned. Returned: success
order_uri string | ACME order URI. Returned: success

### Authors

- Felix Fontein (@felixfontein)

### Collection links

- Issue Tracker
- Repository (Sources)
- Submit a bug report
- Request a feature
- Communication