|maze 17ec4928af vendor: vendorized the deps||5 months ago|
|cmd/amber||5 months ago|
|protocol||5 months ago|
|sql||5 months ago|
|testdata||5 months ago|
|vendor||5 months ago|
|.gitignore||5 months ago|
|Gopkg.lock||5 months ago|
|Gopkg.toml||5 months ago|
|LICENSE||5 months ago|
|README.md||5 months ago|
|amber.conf.example||5 months ago|
|config.go||5 months ago|
|config_test.go||5 months ago|
|handler.go||5 months ago|
|handler_acme.go||5 months ago|
|handler_scep.go||5 months ago|
|issuer.go||5 months ago|
|issuer_test.go||5 months ago|
|nonce.go||5 months ago|
|nonce_test.go||5 months ago|
|server.go||5 months ago|
|x509.go||5 months ago|
Amber is a daemon to provide automatic X.509 Certificate enrollment to various endpoints. It deploys a HTTP server, that, with the help of virtual hosts or paths can serve HTTP-based protocols that can handle the certificate enrollment bits.
Each protocol handler will have a 1:1 mapping to a Certificate Authority profile. To serve multiple Certifificate profiles, either setup multiple virtual paths or virtual hosts.
Amver supports different ways of granting Certificate Signing Requests (CSR) and have them signed by a Certificate Authority (CA). Amber will carry out light-weight checks on the key used to sign the CSR, as well as the names requested, but depends on the policies enforced by the CA for additional checks.
This is a test endpoint that will spin up a self-signed Certificate Authority each time the amber daemon is started. The policy allows any name to be signed. Only suitable for integration tests.
The Hashicorp Vault PKI backend will be used to request signed certificates. For more details on how to setup Vault as a PKI, refer to the Vault documentation at https://www.vaultproject.io/docs/secrets/pki/index.html
The ACME protocol carries out authorization by requesting proofs of (sub)domain ownerships using HTTP, DNS or TLS-SNI probes. Currently only HTTP probes are supported. When the client requests a certificate, the DNS domain names listed in the Common Name (CN) field as well as the subjectAternativeName (SAN) entries are verified by first issuing a challenge and then based on the client’s public key cryptographically verify the response.
The SCEP protocol works with pre-authorizing clients using a pre-shared key (PSK).