New Client/Certificate Manager - Peter SSLers

Client dev
1

For the past few months I’ve been spending some spare time working on an ACME client and certificate manager – Peter SSLers (or how i stopped worrying and learned to love the ssl certificate).

Peter is unfinished, but the basic functionality is complete and has test coverage. The more advanced functionality is not yet complete, but the general API is ironed out and stable enough to finally share.

Peter offers an ACME client that runs via a small pyramid (python) based webserver. Certificates are stored in an RDBMS (by default sqlite is used, but SqlAlchemy is the backing ORM so almost any Database can be used. I personally use PostgreSQL.)

All certificates and keys managed by Peter are decoded and regexed into searchable fields. Most operations are logged into the RDMBS for easy tracking. Peter quickly tells you which certificates or domains need renewal, and everything is cross-referenced.

Peter does a lot of dangerous things and offers no security by design. There are many warnings about this.

Peter is not designed for use in the context of a single webserver or a small number of domains, but is aimed at advanced users who need to manage hundreds of domains or multiple servers within a private LAN. The goal of Peter is to lend a service oriented approach to certificate management and deployment. By centrally managing your ssl certificates, you can easily deploy them to multiple servers. Peter also offers a reference implementation against the ssl_cerficate_by_ hooks on the openresty platform, allowing nginx to dynamically query for ssl certificates as needed, and caching them into nginx and redis if desired.

The first pre-release is available via github under the MIT license: https://github.com/aptise/peter_sslers

Comments and Pull Requests are always welcome.

1 Like
2

No security by design you say? Yee-haw!

Seriously, love the name, and thanks for writing another client. Large-scale certificate management is very useful to have alongside Let’s Encrypt. :slight_smile:

3 Likes
3

Yep! The problem with having "some" amount of security is that people expect the package to be somewhat secure, get lazy, and then get compromised.

The idea is that if you're upfront and scary about "This is insecure!", people are more wary.

So instead of being "Secure", the package is "Security Conscious". The "/admin" and "/public" access is strictly isolated (and admin must be explicitly turned on); but there are no built-in passwords or authentication that might suggest "your data is safe!" -- it's not. The purpose of this project is to offer a toolkit, and the responsibility for security is on the user.

Glad to contribute. The datastore, incidentally, is the "SSL Minnow" :slight_smile:

1 Like
4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.