METHODS¶

account_key( $key_filename )

account_key( \$buffer )

account_key( \%explicit_args )

"account_key" will load a the private account key if it was not already loaded when the "pProtocol::ACME" object was constructed. There are three ways to call this:

If the arg is a SCALAR it is assumed to be the filename of the key. "account_key" will throw an error if there are problems reading the file.

If the arg is a SCALAR reference it is assumed to be a buffer that contains the KEY.

If the arg is a HASH reference it contains named arguments. The arguments are:

   KEY          DEFAUL        DESC
   -----------  -----------   -------------------
   filename     undef         The key Filename
   buffer       undef         Buffer containing the key
   format       undef         Explicitly state the format ( DER | PEM )
    

If both "filename" and "buffer" are set the "buffer" argument will be ignored.

If the format is not explcitly set "Protocol::ACME" will look at the key and try and determine what the format it.

load_key_from_disk( $key_path )

DEPRECATED

Load a key from disk. Currently the key needs to be unencrypted. Callbacks for handling password protected keys are still to come.

directory()

Loads the directory from the ACME host. This call must be made first before any other calls to the API in order the bootstrap the API resource list.

register( %args )

Call the new-reg resource and create an account associated with the loaded account key. If that key has already been registered this method will gracefully and silently handle that.

Arguments that can be passed in:

   KEY                     DEFAULT
   -----------             --------------------
   mailto                  undef
    

mailto: See "new" for a desciption. This will override the value passed to new if any.

accept_tos()

In order to use the Let's Encrypt service, the account needs to accept the Terms of Service. This is provided in a link header in response to the new-reg ( or reg ) resource call. If the TOS have already been accepted as indicated by the reg structure returned by the API this call will be a noop.

authz( $domain )

"authz" needs to be called for each domain ( called identifiers in ACME speak ) in the certificate. This included the domain in the subject as well as the Subject Alternate Name (SAN) fields. Each call to "authz" will result in a challenge being issued from Let's Encrypt. These challenges need to be handled individually.

handle_challenge( $challenge_object )

"handle_challenge" is called for each challenge issued by "authz". The challenge object must be a subclass of "Protocol::ACME::Challenge" which implements a 'handle' method. This objects handle method will be passed three arguments and is expected to fulfill the preconditions for the chosen challenge. The three areguments are:

  fingerprint: the sha256 hex digest of the account key
  token: the challenge token
  url: the url returned by the challenge
    

Fully describing how to handle every challenge type of out of the scope of this documentation ( at least for now ). Two challenge classes have been included for reference:

"Protocol::ACME::Challenge::SimpleSSH" is initialized with the ssh host name and the www root for the web server for the http-01 challenge. It will ssh to the host and create the file in the correct location for challenge fulfillment.

"Protocol::ACME::Challenge::LocalFile" is initialized with just the www root for the web server for the http-01 challenge. It will simply create the challenge file in the correct place on the local filesystem.

"Protocol::ACME::Challenge::Manual" is intended to be run in an interactive manner and will stop and prompt the user with the relevant information so they can fulfill the challenge manually.

but below is an example for handling the simpleHTTP ( http-01 ) challenge.

check_challenge()

Called after "handle_challenge". This will poll the challenge status resource and will return when the state changes from 'pending'.

cleanup_challenge()

Called after "check_challenge" to remove the challenge files.

$cert = sign( $csr_filename )

$cert = sign( \$buffer )

$cert = sign( \%explicit_args )

Call "sign" after the challenge for each domain ( itentifier ) has been fulfilled. There are three ways to call this:

If the arg is a SCALAR it is assumed to be the filename of the CSR. "sign" will throw an error if there are problems reading the file.

If the arg is a SCALAR reference it is assumed to be a buffer that contains the CSR.

If the arg is a HASH reference it contains named arguments. The arguments are:

   KEY          DEFAUL        DESC
   -----------  -----------   -------------------
   filename     undef         The CSR Filename
   buffer       undef         Buffer containing the CSR
   format       undef         Explicitly state the format ( DER | PEM )
    

If both "filename" and "buffer" are set the "buffer" argument will be ignored.

If the format is not explcitly set Protocol::ACME will look at the CSR and try and determine what the format it.

On success "Protocol::ACME" will return the DER encoded signed certificate.

$cert_chain = chain()

After "sign" has been called and a cert successfully created, "chain" will fetch and return the DER encoded certificate issuer.

revoke( $certfile )

Call "revoke" to revoke an already issued certificate. $certfile must point the a DER encoded form of the certificate.

recovery_key()

LE does not yet support recovery keys. This method will die when called.