# community.crypto.acme_certificate_order_info module – Obtain information for an ACME v2 order — Community.Crypto Collection documentation

# community.crypto.acme_certificate_order_info module – Obtain information for 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_info`.

New in community.crypto 2.21.0

## Synopsis

- Obtain information for an ACME v2 order. This can be used during the process 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.

- This module needs to be used in conjunction with the community.crypto.acme_certificate_order_create, community.crypto.acme_certificate_order_validate, and community.crypto.acme_certificate_order_finalize modules.

## 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`

order_uri string / required | The order URI provided by `order_uri`.
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: full This action does not modify state. | Can run in `check_mode` and return changed status prediction without modifying target.
diff_mode | Support: N/A This action does not modify state. | 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_create

  Create an ACME order.

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.

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_inspect

  Allows to debug problems.

community.crypto.acme_certificate_deactivate_authz

  Allows to deactivate (invalidate) ACME v2 orders.

## Examples

    - 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: order

    - name: Obtain information on the order
      community.crypto.acme_certificate_order_info:
        account_key_src: /etc/pki/cert/private/account.key
        order_uri: "{{ order.order_uri }}"
      register: order_info

    - name: Show information
      ansible.builtin.debug:
        var: order_info

## 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
authorizations_by_identifier dictionary | A dictionary mapping identifiers to their authorization objects. Returned: success
identifier dictionary | The keys in this dictionary are the identifiers. `identifier` is a placeholder used in the documentation. See https://www.rfc-editor.org/rfc/rfc8555#section-7.1.4 for how authorization objects look like. Returned: success

challenges

list / elements=dictionary

For pending authorizations, the challenges that the client can fulfill in order to prove possession of the identifier.

For valid authorizations, the challenge that was validated.

For invalid authorizations, the challenge that was attempted and failed.

Each array entry is an object with parameters required to validate the challenge. A client should attempt to fulfill one of these challenges, and a server should consider any one of the challenges sufficient to make the authorization valid.

See https://www.rfc-editor.org/rfc/rfc8555#section-8 for the general structure. The structure of every entry depends on the challenge’s type. For `tls-alpn-01` challenges, the structure is defined in https://www.rfc-editor.org/rfc/rfc8737.html#section-3.

Returned: always

error dictionary | Error that occurred while the server was validating the challenge, if any. This field is structured as a problem document according to RFC 7807. Returned: always if `authorizations_by_identifier.identifier.challenges[].type=invalid`, otherwise in some situations

status

string

The status of this challenge.

See https://www.rfc-editor.org/rfc/rfc8555#section-7.1.6 for state changes.

Returned: always

Can only return:

- `"pending"`

- `"processing"`

- `"valid"`

- `"invalid"`

type

string

The type of challenge encoded in the object.

Returned: always

Can only return:

- `"http-01"`

- `"dns-01"`

- `"tls-alpn-01"`

url string | The URL to which a response can be posted. Returned: always
validated string | The time at which the server validated this challenge. Encoded in the format specified in RFC 3339. Returned: always if `authorizations_by_identifier.identifier.challenges[].type=valid`, otherwise in some situations
expires string | The timestamp after which the server will consider this authorization invalid. Encoded in the format specified in RFC 3339. Returned: if `authorizations_by_identifier.identifier.status=valid`, and sometimes in other situations
identifier dictionary | The identifier that the account is authorized to represent. Returned: always

type

string

The type of identifier.

So far `dns` and `ip` are defined values.

Returned: always

Can only return:

- `"dns"`

- `"ip"`

Sample: `"dns"`

value string | The identifier itself. Returned: always Sample: `"example.com"`

status

string

The status of this authorization.

See https://www.rfc-editor.org/rfc/rfc8555#section-7.1.6 for state changes.

Returned: always

Can only return:

- `"pending"`

- `"valid"`

- `"invalid"`

- `"deactivated"`

- `"expired"`

- `"revoked"`

wildcard boolean | This field must be present and true for authorizations created as a result of a `newOrder` request containing a DNS identifier with a value that was a wildcard domain name. For other authorizations, it must be absent. Wildcard domain names are described in https://www.rfc-editor.org/rfc/rfc8555#section-7.1.3 of the ACME specification. Returned: sometimes
authorizations_by_status dictionary | For every status, a list of identifiers whose authorizations have this status. Returned: success
deactivated list / elements=string | A list of all identifiers whose authorizations are in the `deactivated` state. See https://www.rfc-editor.org/rfc/rfc8555#section-7.1.6 for state changes of authorizations. Returned: always
expired list / elements=string | A list of all identifiers whose authorizations are in the `expired` state. See https://www.rfc-editor.org/rfc/rfc8555#section-7.1.6 for state changes of authorizations. Returned: always
invalid list / elements=string | A list of all identifiers whose authorizations are in the `invalid` state. See https://www.rfc-editor.org/rfc/rfc8555#section-7.1.6 for state changes of authorizations. Returned: always
pending list / elements=string | A list of all identifiers whose authorizations are in the `pending` state. See https://www.rfc-editor.org/rfc/rfc8555#section-7.1.6 for state changes of authorizations. Returned: always
revoked list / elements=string | A list of all identifiers whose authorizations are in the `revoked` state. See https://www.rfc-editor.org/rfc/rfc8555#section-7.1.6 for state changes of authorizations. Returned: always
valid list / elements=string | A list of all identifiers whose authorizations are in the `valid` state. See https://www.rfc-editor.org/rfc/rfc8555#section-7.1.6 for state changes of authorizations. Returned: always
order dictionary | The order object. See https://www.rfc-editor.org/rfc/rfc8555#section-7.1.3 for its specification. Returned: success

authorizations

list / elements=string

For pending orders, the authorizations that the client needs to complete before the requested certificate can be issued, including unexpired authorizations that the client has completed in the past for identifiers specified in the order.

The authorizations required are dictated by server policy; there may not be a 1:1 relationship between the order identifiers and the authorizations required.

For final orders (in the `valid` or `invalid` state), the authorizations that were completed. Each entry is a URL from which an authorization can be fetched with a POST-as-GET request.

The authorizations themselves are returned as `authorizations_by_identifier`.

Returned: always

certificate string | A URL for the certificate that has been issued in response to this order. Returned: when the certificate has been issued
error dictionary | The error that occurred while processing the order, if any. This field is structured as a problem document according to RFC 7807. Returned: sometimes
expires string | The timestamp after which the server will consider this order invalid. Encoded in the format specified in RFC 3339. Returned: if `order.status` is `pending` or `valid`, and sometimes in other situations
finalize string | A URL that a CSR must be POSTed to once all of the order’s authorizations are satisfied to finalize the order. The result of a successful finalization will be the population of the certificate URL for the order. Returned: always
identifiers list / elements=dictionary | An array of identifier objects that the order pertains to. Returned: always

type

string

The type of identifier.

So far `dns` and `ip` are defined values.

Returned: always

Can only return:

- `"dns"`

- `"ip"`

Sample: `"dns"`

value string | The identifier itself. Returned: always Sample: `"example.com"`
notAfter (optional, string) string | The requested value of the `notAfter` field in the certificate. Encoded in the date format defined in RFC 3339. Returned: depending on order
notBefore string | The requested value of the `notBefore` field in the certificate. Encoded in the date format defined in RFC 3339. Returned: depending on order

status

string

The status of this order.

See https://www.rfc-editor.org/rfc/rfc8555#section-7.1.6 for state changes.

Returned: always

Can only return:

- `"pending"`

- `"ready"`

- `"processing"`

- `"valid"`

- `"invalid"`

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