community.crypto.acme_account module – Create, modify or delete ACME accounts
Note
This module is part of the community.crypto collection (version 2.22.1).
You might already have this collection installed if you are using the ansible
package.
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_account
.
Synopsis
Allows to create, modify or delete accounts with a CA supporting the ACME protocol, such as Let’s Encrypt.
This module only works with the ACME v2 protocol.
Requirements
The below requirements are needed on the host that executes this module.
either openssl or cryptography >= 1.5
ipaddress
Parameters
Parameter |
Comments |
---|---|
Content of the ACME account RSA or Elliptic Curve key. Mutually exclusive with Required if 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 |
|
Phassphrase to use to decode the account key. Note: this is not supported by the |
|
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 Mutually exclusive with Required if |
|
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. |
|
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. |
|
The ACME version of the endpoint. Must be The value Choices:
|
|
Whether account creation is allowed (when state is Choices:
|
|
A list of contact URLs. Email addresses must be prefixed with See https://tools.ietf.org/html/rfc8555#section-7.3 for what is allowed. Must be specified when state is Default: |
|
Allows to provide external account binding data during account creation. This is used by CAs like Sectigo to bind a new ACME account to an existing CA-specific account, to be able to properly identify a customer. Only used when creating a new account. Can not be specified for ACME v1. |
|
The MAC algorithm provided by the CA. If not specified by the CA, this is probably Choices:
|
|
Base64 URL encoded value of the MAC key provided by the CA. Padding ( |
|
The key identifier provided by the CA. |
|
Content of the ACME account RSA or Elliptic Curve key to change to. Same restrictions apply as to Mutually exclusive with Required if |
|
Phassphrase to use to decode the new account key. Note: this is not supported by the |
|
Path to a file containing the ACME account RSA or Elliptic Curve key to change to. Same restrictions apply as to Mutually exclusive with Required if |
|
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: |
|
Determines which crypto backend to use. The default choice is If set to If set to Choices:
|
|
The state of the account, to be identified by its account key. If the state is If the state is Choices:
|
|
Boolean indicating whether you agree to the terms of service document. ACME servers can require this to be Choices:
|
|
Whether calls to the ACME directory will validate TLS certificates. Warning: Should only ever be set to Choices:
|
Attributes
Attribute |
Support |
Description |
---|---|---|
Action groups: community.crypto.acme, acme |
Use |
|
Support: full |
Can run in |
|
Support: full |
Will return details on what has changed (or possibly needs changing in |
Notes
Note
The community.crypto.acme_certificate module also allows to do basic account management. When using both modules, it is recommended to disable account management for community.crypto.acme_certificate. For that, use the
modify_account
option of community.crypto.acme_certificate.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 theopenssl
binary. This can be explicitly disabled or enabled with theselect_crypto_backend
option. Note that using theopenssl
binary will be slower and less secure, as private key contents always have to be stored on disk (seeaccount_key_content
).
See Also
See also
- Automatic Certificate Management Environment (ACME)
The specification of the ACME protocol (RFC 8555).
- community.crypto.acme_account_info
Retrieves facts about an ACME account.
- community.crypto.openssl_privatekey
Can be used to create a private account key.
- community.crypto.openssl_privatekey_pipe
Can be used to create a private account key without writing it to disk.
- community.crypto.acme_inspect
Allows to debug problems.
Examples
- name: Make sure account exists and has given contacts. We agree to TOS.
community.crypto.acme_account:
account_key_src: /etc/pki/cert/private/account.key
state: present
terms_agreed: true
contact:
- mailto:[email protected]
- mailto:[email protected]
- name: Make sure account has given email address. Do not create account if it does not exist
community.crypto.acme_account:
account_key_src: /etc/pki/cert/private/account.key
state: present
allow_creation: false
contact:
- mailto:[email protected]
- name: Change account's key to the one stored in the variable new_account_key
community.crypto.acme_account:
account_key_src: /etc/pki/cert/private/account.key
new_account_key_content: '{{ new_account_key }}'
state: changed_key
- name: Delete account (we have to use the new key)
community.crypto.acme_account:
account_key_content: '{{ new_account_key }}'
state: absent
Return Values
Common return values are documented here, the following are the fields unique to this module:
Key |
Description |
---|---|
ACME account URI, or None if account does not exist. Returned: always |