sleevi

CT For Server (Developers)

Intro

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,

garybernhardt

This document has moved!

It's now here, in The Programmer's Compendium. The content is the same as before, but being part of the compendium means that it's actively maintained.

electerious

mime {
    .atom application/atom+xml
    .json application/json
    .map application/json
    .topojson application/json
    .jsonld application/ld+json
    .rss application/rss+xml
    .geojson application/vnd.geo+json
    .rdf application/xml
    .xml application/xml

AGWA

Date: Mon, 5 Oct 2015 16:34:03 -0700

Apache caches an OCSP response for one hour by default. Unfortunately, once the hour is up, the response is purged from the cache, and Apache doesn't attempt to retrieve a new one until the next TLS handshake takes place. That means that if there's a problem contacting the OCSP responder at that moment, Apache is left without an OCSP response to staple. Furthermore, it caches the non-response for 10 minutes (by default), so for the next 10 minutes, no OCSP response will be stapled to your

ericclemmons

Using <details> in GitHub

Suppose you're opening an issue and there's a lot noisey logs that may be useful.

Rather than wrecking readability, wrap it in a <details> tag!

<details>
 Summary Goes Here

kennwhite

#!/bin/bash
# *As root*

cd ~
killall caddy
rm -rf ~/caddy
mkdir caddy && cd caddy
curl -SL 'https://caddyserver.com/download/build?os=linux&arch=amd64&features=hugo' > caddy.tgz
tar xzf caddy.tgz 

phred

fff.red {
    header / {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        Content-Security-Policy "default-src https:*"
        Public-Key-Pins "pin-sha256=\"ckOIjdimiwD3mfMmkmCh7uiJCBtXvoqoBoKKB1K5UIM=\"; pin-sha256=\"QiTyymM4e635OgWkx9d7nq5xvEuqmgV7HiDjIIGyymo=\"; max-age=2592000"
        X-Frame-Options SAMEORIGIN
        X-XSS-Protection "1; mode=block"
        X-Content-Type-Options nosniff
    }
}

hlandau

This is a rough sketch I've put together in my mind of how an 'ACME daemon' might end up looking.

API

acmetool is designed for batch operation which works well for small use cases but large scale deployments will work better with a daemon. This will probably expose a service via an HTTP API, so that arbitrary parts of a service provider's stack can request certificates.

This API will need to be asynchronous as it may take arbitrarily long for 'acmed'

j-mcnally

config_server "https://etcd.local:2379"

service users {
  endpoint: "/users",
  proxy: "{{services.users.ip}}:{{services.users.port}}"
}


# In this example 'services.users' would be a directory with a json key for every user service container / application. 
# Using this we could template the proxy and any other information in the services block, and it would just work with caddy.

captncraig

apt-get update
apt-get install -y curl git mercurial make binutils bison gcc build-essential

git clone https://go.googlesource.com/go go14
git clone go14 go15
git clone go14 go16

#build all go versions
cd go14/src