Download the PHP package yourivw/leclient without Composer

LEClient

PHP LetsEncrypt client library for ACME v2. The aim of this client is to make an easy-to-use and integrated solution to create a LetsEncrypt-issued SSL/TLS certificate with PHP. The user has to have access to the web server or DNS management to be able to verify the domain is accessible/owned by the user.

Current version

The current version is 1.2.2

Getting Started

These instructions will get you started with this client library. If you have any questions or find any problems, feel free to open an issue and I'll try to have a look at it.

Also have a look at the LetsEncrypt documentation for more information and documentation on LetsEncrypt and ACME.

Prerequisites

The minimum required PHP version is 5.2.0. Version 7.1.0 is required for EC keys. The function generating EC keys will throw an exception when trying to generate EC keys with a PHP version below 7.1.0.

Version 1.0.0 will be kept available, but will not be maintained.

This client also depends on cURL and OpenSSL.

Installing

Using composer:

It is advisable to cut the script some slack regarding execution time by setting a higher maximum time. There are several ways to do so. One is to add the following to the top of the page:

Usage

The basic functions and its necessary arguments are shown here. An extended description is included in each class.

As of version 1.1.6, it is also possible to initiate the LEClient with a PSR-3 logger (\Psr\Log\LoggerInterface).

Initiating the client:

The client will automatically create a new account if there isn't one found. It will forward the e-mail address(es) supplied during initiation, as shown above.

Using the account functions:

Creating a certificate order instance. If there is an order found, stored locally, it will use this order. Otherwise, it will create a new order. If the supplied domain names don't match the order, a new order is created as well. The construction of the LetsEncrypt Order instance:

Using the order functions:

Supportive functions:

Filesystem Structure

LEClient stores account keys, certificate keys, certificates and order data in the filesystem. By default, the folder structure used will look like this, relative to your working directory:

keys/                   Top-level LEClient folder
  public.pem            Your certificate’s public key
  private.pem           Your certificate’s private key
  order                 A file used to store the order URL
  fullchain.crt         The full-chain certificate
  certificate.crt       The certificate
  __account/            An internal folder for LEClient to store your account keys
    public.pem          Your ACME account’s public key
    private.pem         Your ACME account’s private key
    .htaccess           An automatically-generated .htaccess to prevent accidental exposure

You can customise these locations by passing values to the $certificateKeys and $accountKeys construction parameters when creating an LEClient.

Passing strings will change the location and name of the top-level LEClient folder, and the name of the Account Key folder. Note that when passing strings, the account key folder will always be a subfolder of the top-level folder, meaning that:

will result in the following structure:

path/to/my/key/folder/
  public.pem
  …
  my_account_folder/
    public.pem
    …

If you want to have more control over the exact locations the various files are stored in, you can instead pass arrays to the $certificateKeys and $accountKeys parameters. If you pass an array to one, you must pass arrays to both.

Authorization challenges

LetsEncrypt (ACME) performs authorizations on the domains you want to include on your certificate, to verify you actually have access to the specific domain. Therefore, when creating an order, an authorization is added for each domain. If a domain has recently (in the last 30 days) been verified by your account, for example in another order, you don't have to verify again. At this time, a domain can be verified by a HTTP request to a file (http-01) or a DNS TXT record (dns-01). The client supplies the necessary data for the chosen verification by the call to getPendingAuthorizations(). Since creating a file or DNS record differs for every server, this is not implemented in the client. After the user has fulfilled the challenge requirements, a call has to be made to verifyPendingOrderAuthorization(). This client will first verify the challenge with checkHTTPChallenge() or checkDNSChallenge() by itself, before it is starting the verification by LetsEncrypt. Keep in mind, a wildcard domain can only be verified with a DNS challenge. An example for both challenges is shown below.

HTTP challenge

For this example, we assume there is one domain left to verify.

This returns an array:

For a successful verification, a request will be made to the following URL:

The content of this file should be set to the content in the array above. The user should create this file before it can verify the authorization.

DNS challenge

For this example, we assume there are two domains left to verify. One is a wildcard domain. The second domain in this example is added for demonstration purposes. Adding a subdomain to the certificate which is also already covered by the wildcard domain is does not offer much added value.

This returns an array:

For a successful verification, DNS records should be created as follows:

The TTL value can be set higher if wanted or necessary, I prefer to keep it as low as possible for this purpose. To make sure the verification is successful, it would be advised to run a script using DNS challenges in two parts, with a certain amount of time in between to allow for the DNS record to update. The user himself should make sure to set this DNS record before the record can be verified. The DNS record name also depends on your provider, therefore getPendingAuthorizations() does not give you a ready-to-use record name. Some providers only accept a name like _acme-challenge, without the top domain name, for _acme-challenge.example.org. Some providers accept (require?) a full name like shown above.

A wildcard domain, like `.example.org, will be verified asexample.org, as shown above. This means the DNS record name should be_acme-challenge.example.org`*

Full example

For both HTTP and DNS authorizations, a full example is available in the project's main code directory. The HTTP authorization example is contained in one file. As described above, the DNS authorization example is split into two parts, to allow for the DNS record to update in the meantime. While the TTL of the record might be low, it can sometimes take some time for your provider to update your DNS records after an amendment.

If you can't get these examples, or the client library to work, try and have a look at the LetsEncrypt documentation mentioned above as well. In order for the example code to work, make sure to replace all 'example.org' information with your own information. The examples will fail when you run them using the preset example data.

Security

Security is an important subject regarding SSL/TLS certificates, of course. Since this client is a PHP script, it is likely this code is running on a web server. It is obvious that your private key, stored on your web server, should never be accessible from the web. When the client created the keys directory for the first time, it will store a .htaccess file in this directory, denying all visitors. Always make sure yourself your keys aren't accessible from the web! I am in no way responsible if your private keys go public. If this does happen, the easiest solution is to change your account keys (described above) or deactivate your account and create a new one. Next, create a new certificate.

License

This project is licensed under the MIT License - see the LICENSE file for details.