The specification, template, and tests for creating an le-store- strategy for Let's Encrypt v2 / ACME using greenlock.js.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
CaptEmulation c58785f6e3 Updates from writing my own store 3 months ago
tests Updates from writing my own store 3 months ago
.gitignore Initial commit 2 years ago
LICENSE Initial commit 2 years ago
README.md update link 7 months ago
index.js Updates from writing my own store 3 months ago

README.md

le-store-SPEC

| Sponsored by ppl | greenlock.js |

The reference implementation, specification, template, and tests for creating an le-store- strategy.

The reference implementation is completely in-memory.

See Help Wanted: Database Plugins (for saving certs)

How to create a custom strategy

READ THIS README: Believe it or not, most of your answers are either right here or in the comments in the sample code in index.js.

Now, let’s say there’s some new database AwesomeDB that we want to make a plugin for, here’s how we’d start:

# First create you repo on github or wherever
# Then clone it
git clone git@github.com:AwesomeDB/le-store-awesome.git

pushd le-store-awesome

# IMPORTANT: we pull in the 'template' branch, which has the skeleton code
git pull https://git.coolaj86.com/coolaj86/le-store-SPEC.js.git template

git push

Or, if you already have some code and just need to merge in the tests:

git pull https://git.coolaj86.com/coolaj86/le-store-SPEC.js.git tests

Next, Just run the tests

node tests/basic.js

Note: you should not modify the tests that come from the tests branch, but rather create separate files for your own tests.

API

* getOptions()
* accounts.
  * checkKeypair(opts, cb)
  * setKeypair(opts, keypair, cb)
  * check(opts, cb)
  * set(opts, reg, cb)
* certificates.
  * checkKeypair(opts, cb)
  * setKeypair(opts, keypair, cb)
  * check(opts, cb)
  * set(opts, certs, cb)

Keypairs

For convenience, the keypair object will always contain both PEM and JWK versions of the private and/or public keys when being passed to the *Keypair functions.

set

setKeypair will always be called with email and all three forms of the keypair: privateKeyPem, publicKeyPem, and privateKeyJwk. It’s easy to generate publicKeyJwk from privateKeyJwk because it is just a copy of the public fields e and n.

// keypair looks like this
{ privateKeyPem: '...'
, publicKeyPem: '...'
, privateKeyJwk: { ... }
}

check

checkKeypair may be called with any of email, accountId, and keypair - which will contain only publicKeyPem and publicKeyJwk.

// opts looks like this
{
  email: '...@...'
, accountId: '...'
, keypair: {
    publicKeyPem: '...'
  , publicKeyJwk: { ... }
  }
}