Skip to content

Instantly share code, notes, and snippets.


Block or report user

Report or block sleevi

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
sleevi /
Last active Jan 17, 2020
Draft SC26

CA/Browser Forum

Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates

CA/Browser Forum

Version 1.6.7

View cert.cnf
default_bits = 2048
default_md = sha256
string_mask = utf8only
prompt = no
encrypt_key = no
distinguished_name = @req_dn
x509_extensions = @req_ext
sleevi /
Created Apr 19, 2017
CT Best Practices (April 2017)

CT For Server (Developers)


Similar to my advice regarding OCSP Stapling for servers/server developers, based on questions I've received about "CT best practices," I wanted to write something similar for those writing server software. That is, this isn't targeted at server operators, but for those writing software like Apache, nginx, Caddy, etc.

At the most basic level, the deployment of Certificate Transparency to date has largely tried to focus the burden on CAs, rather than on server developers. If the CA is doing everything right,


On Twitter the other day, I was lamenting the state of OCSP stapling support on Linux servers, and got asked by several people to write-up what I think the requirements are for OCSP stapling support.

  1. Support for keeping a long-lived (disk) cache of OCSP responses.

    This should be fairly simple. Any restarting of the service shouldn't blow away previous responses that were obtained. This doesn't need to be disk, just stable - and disk is an easy stable storage for most server

You can’t perform that action at this time.