letsencrypt / boulder

An ACME-based certificate authority, written in Go.

Boulder - An ACME CA

This is an implementation of an ACME-based CA. The ACME protocol allows the CA to automatically verify that an applicant for a certificate actually controls an identifier, and allows domain holders to issue and revoke certificates for their domains. Boulder is the software that runs Let's Encrypt.

Contents

• Overview
• Setting up Boulder
  • Development
  • Working with Certbot
  • Working with another ACME Client
  • Production
• Contributing
• License

Overview

Boulder is divided into the following main components:

1. Web Front Ends (one per API version)
2. Registration Authority
3. Validation Authority
4. Certificate Authority
5. Storage Authority
6. Publisher
7. OCSP Responder
8. CRL Updater

This component model lets us separate the function of the CA by security context. The Web Front End, Validation Authority, OCSP Responder and Publisher need access to the Internet, which puts them at greater risk of compromise. The Registration Authority can live without Internet connectivity, but still needs to talk to the Web Front End and Validation Authority. The Certificate Authority need only receive instructions from the Registration Authority. All components talk to the SA for storage, so most lines indicating SA RPCs are not shown here.

                            CA ---------> Publisher
                             ^
                             |
       Subscriber -> WFE --> RA --> SA --> MariaDB
                             |               ^
Subscriber server <- VA <----+               |
                                             |
          Browser -------------------> OCSP Responder

Internally, the logic of the system is based around five types of objects: accounts, authorizations, challenges, orders and certificates, mapping directly to the resources of the same name in ACME. Requests from ACME clients result in new objects and changes to objects. The Storage Authority maintains persistent copies of the current set of objects.

Boulder uses gRPC for inter-component communication. For components that you want to be remote, it is necessary to instantiate a "client" and "server" for that component. The client implements the component's Go interface, while the server has the actual logic for the component. A high level overview for this communication model can be found in the gRPC documentation.

The full details of how the various ACME operations happen in Boulder are laid out in DESIGN.md.

Setting up Boulder

Development

Boulder has a Dockerfile and uses Docker Compose to make it easy to install and set up all its dependencies. This is how the maintainers work on Boulder, and is our main recommended way to run it for development/experimentation. It is not suitable for use as a production environment.

While we aim to make Boulder easy to setup ACME client developers may find Pebble, a miniature version of Boulder, to be better suited for continuous integration and quick experimentation.

We recommend setting git's fsckObjects setting before getting a copy of Boulder to have better integrity guarantees for updates.

Clone the boulder repository:

git clone https://github.com/letsencrypt/boulder/
cd boulder

Additionally, make sure you have Docker Engine 1.13.0+ and Docker Compose 1.10.0+ installed. If you do not, you can follow Docker's installation instructions.

We recommend having at least 2GB of RAM available on your Docker host. In practice using less RAM may result in the MariaDB container failing in non-obvious ways.

To start Boulder in a Docker container, run:

docker compose up

To run our standard battery of tests (lints, unit, integration):

docker compose run --use-aliases boulder ./test.sh

To run all unit tests:

docker compose run --use-aliases boulder ./test.sh --unit

To run specific unit tests (example is of the ./va directory):

docker compose run --use-aliases boulder ./test.sh --unit --filter=./va

To run all integration tests:

docker compose run --use-aliases boulder ./test.sh --integration

To run specific integration tests (example runs TestAkamaiPurgerDrainQueueFails and TestWFECORS):

docker compose run --use-aliases boulder ./test.sh --filter TestAkamaiPurgerDrainQueueFails/TestWFECORS

To get a list of available integration tests:

docker compose run --use-aliases boulder ./test.sh --list-integration-tests

The configuration in docker-compose.yml mounts your boulder checkout at /boulder so you can edit code on your host and it will be immediately reflected inside the Docker containers run with docker compose.

If you have problems with Docker, you may want to try removing all containers and volumes.

By default, Boulder uses a fake DNS resolver that resolves all hostnames to 127.0.0.1. This is suitable for running integration tests inside the Docker container. If you want Boulder to be able to communicate with a client running on your host instead, you should find your host's Docker IP with:

ifconfig docker0 | grep "inet addr:" | cut -d: -f2 | awk '{ print $1}'

And edit docker-compose.yml to change the FAKE_DNS environment variable to match. This will cause Boulder's stubbed-out DNS resolver (sd-test-srv) to respond to all A queries with the address in FAKE_DNS.

If you use a host-based firewall (e.g. ufw or iptables) make sure you allow connections from the Docker instance to your host on the required validation ports to your ACME client.

Alternatively, you can override the docker-compose.yml default with an environmental variable using -e (replace 172.17.0.1 with the host IPv4 address found in the command above)

docker compose run --use-aliases -e FAKE_DNS=172.17.0.1 --service-ports boulder ./start.py

Running tests without the ./test.sh wrapper:

Run all unit tests

docker compose run --use-aliases boulder go test -p 1 ./...

Run unit tests for a specific directory:

docker compose run --use-aliases boulder go test <DIRECTORY>

Run integration tests (omit --filter <REGEX> to run all):

docker compose run --use-aliases boulder python3 test/integration-test.py --chisel --gotest --filter <REGEX>

Working with Certbot

Check out the Certbot client from https://github.com/certbot/certbot and follow their setup instructions. Once you've got the client set up, you'll probably want to run it against your local Boulder. There are a number of command line flags that are necessary to run the client against a local Boulder, and without root access. The simplest way to run the client locally is to use a convenient alias for certbot (certbot_test) with a custom SERVER environment variable:

SERVER=http://localhost:4001/directory certbot_test certonly --standalone -d test.example.com

Your local Boulder instance uses a fake DNS resolver that returns 127.0.0.1 for any query, so you can use any value for the -d flag. To return an answer other than 127.0.0.1 change the Boulder FAKE_DNS environment variable to another IP address.

Working with another ACME Client

Once you have followed the Boulder development environment instructions and have started the containers you will find the ACME endpoints exposed to your host at the following URLs:

• ACME v2, HTTP: http://localhost:4001/directory
• ACME v2, HTTPS: https://localhost:4431/directory

To access the HTTPS versions of the endpoints you will need to configure your ACME client software to use a CA truststore that contains the test/wfe-tls/minica.pem CA certificate. See test/PKI.md for more information.

Your local Boulder instance uses a fake DNS resolver that returns 127.0.0.1 for any query, allowing you to issue certificates for any domain as if it resolved to your localhost. To return an answer other than 127.0.0.1 change the Boulder FAKE_DNS environment variable to another IP address.

Most often you will want to configure FAKE_DNS to point to your host machine where you run an ACME client.

Production

Boulder is custom built for Let's Encrypt and is intended only to support the Web PKI and the CA/Browser forum's baseline requirements. In our experience often Boulder is not the right fit for organizations that are evaluating it for production usage. In most cases a centrally managed PKI that doesn't require domain-authorization with ACME is a better choice. For this environment we recommend evaluating a project other than Boulder.

We offer a brief deployment and implementation guide that describes some of the required work and security considerations involved in using Boulder in a production environment. As-is the docker based Boulder development environment is not suitable for production usage. It uses private key material that is publicly available, exposes debug ports and is brittle to component failure.

While we are supportive of other organization's deploying Boulder in a production setting we prioritize support and development work that favors Let's Encrypt's mission. This means we may not be able to provide timely support or accept pull-requests that deviate significantly from our first line goals. If you've thoroughly evaluated the alternatives and Boulder is definitely the best fit we're happy to answer questions to the best of our ability.

Contributing

Please take a look at CONTRIBUTING.md for our guidelines on submitting patches, code review process, code of conduct, and various other tips related to working on the codebase.

Code of Conduct

The code of conduct for everyone participating in this community in any capacity is available for reference on the community forum.

License

This project is licensed under the Mozilla Public License 2.0, the full text of which can be found in the LICENSE.txt file.

boulder's Issues

Check for weak keys

We need to check for keys less than 2048 bits and known weak private keys, per CPS.

The automated process will also verify the Public Key of a Device that is requested has less than 2048 bit encryption and if it uses a known weak Private Key. If either or both are automatically detected in the secure session, the Applicant will be required to correct the determined issue before the DV-SSL Certificate can be issued.

Implement CAA

We should observe CAA records in DNS.

Update README for initial setup

Now when I try to start up Boulder, I get this error:

$ ./bin/boulder-start monolithic
amqp://guest:guest@localhost:5672
localhost:8888


2015/03/12 17:49:36 [DEBUG] validating configuration
2015/03/12 17:49:36 [DEBUG] validate remote profile
2015/03/12 17:49:36 [DEBUG] invalid remote profile: no remote signer specified
2015/03/12 17:49:36 [DEBUG] default profile is invalid
Unable to create CA: {"code":5200,"message":"Invalid or unknown policy"}

I'm guessing this is because I need to be running a cfssl instance locally. Could you please add instructions to the README, @bifurcation?

Support MySQL in the Storage Authority

SA should accept a mysql connect string, optionally, to override the sqlite string.
Bonus points if we can also redirect to another sqlite DB...

Client certificates

Will it be possible to use a Let's Encrypt certificate to sign client certificates yourself, or will it be possible to request client certificates from Let's Encrypt?

Content-type: application/json missing

The content-type header is currently sent as 'content-type': 'text/plain; charset=utf-8'
All of the messages besides the certificate should set the Header to application/json.

Implement DNS Validator in VA

See certbot/certbot#200.

The client just needs a server counterpart. :)

Implement schema for keeping tracking of expiration warning emails

We want to be able to keep track of whether we sent an email. We probably also want to be able to keep track of sending multiple nags at different time scales.

Google Certificate Transparency (CT) support

Chrome is not currently supporting a hard CT requirement for EV or DV certs, and hasn't announced when it plans to do so. We can and should participate in CT, but clients won't get any obvious indication of its absence. We should make a public statement that ever certificate we issue will be submitted to a CT log, and third-party monitors can collect certs from the Internet and check logs to keep us honest.

Subscribers that want to provide a CT proof can do so with the OCSP Stapling technique (recommended) or the TLS Extension technique. I haven't yet investigated whether we can bundle the CT proof with the regular OCSP responses we send.

To implement CT, we can use a polling component that exists outside of our firewall. This component will continuously query Let's Encrypt's certificate repository for new certificates, and submit those certificates to the appropriate logs.

To do this we'll need to update the certificate repository code in Boulder so that it can be used to query for new certificates. One simple way to do this: In addition to querying by serial numbers (implemented), we could allow querying by the sequential part of the serial number. This would return all certificates with serial numbers greater than the sequential part queried and less than the next increment of the sequential part. Assuming everything is functioning correctly, that should be exactly one certificate. The CT poller would fetch and store each certificate until gets a 404, then poll that number until it resolves, and so on.

DVSNI Verification Invalid

I was wondering why I couldn't solve DVSNI challenges.

boulder/va/validation-authority.go

Line 96 in 8dc0012

hostPort := "localhost:5001"

It appears that the localhost:5001 line can be removed and line below can be uncommented.

Rework Dockerfile to handle the multiple-cmdlines.

PR #48 breaks the Docker build. Minimally, Dockerfile will need to stop using the boulder-start entrypoint. It may be easier to place a Dockerfile into each cmd/ directory.

prefer Go 1.5+ for ECDSA nonce safety

The ECDSA implementation in golang 1.4.x can leak the private key if message nonces are predictable, e.g. due to intermittent PRNG failure. My colleague David Gil fixed this in https://go-review.googlesource.com/#/c/3340/

I'm not sure Boulder actually signs anything with ECDSA, so perhaps this is a non-issue.

Issue without CN

The current logic in IssueCertificate only includes the CommonName in subjectAlternateNames if there were no subjectAlternateNames provided in the CSR. Instead, we should always add the CommonName to the subjectAlternateNames if it is not already present there.

Additional SANs in CSR are ignored

When I use the LE client to request a certificate for more than one hostname, only the first one seems to be included in the certificate. All additional hostnames seem to be ignored. However, the CSR which is generated appears to be correct - the problem seems to be occurring at the boulder end.

e.g. I request a cert for "example.org,www.example.org"
The CSR has CN=example.org, SAN={example.org,www.example.org}

Expected cert:
CN=example.org, SAN={example.org,www.example.org}

Actual issued cert:
CN=example.org, SAN={example.org}

I can't see any obvious error in certificate-authority.go - is this a bug upstream in CFSSL perhaps?

Test that CA checks that sufficient authorizations are present before issuing certificate

Currently certificate-authority.go has this comment:

// XXX Take in authorizations and verify that union covers CSR?

We should fix that.

URLs should be configurable and not only http://0.0.0.0:4000/

Send mail in advance of certificate expiration via periodic tasks

The CPS under which IdenTrust is cross-certifying us requires advance notice of certificate expiration, so our CPS also needs to include advance notice. To do this we need to implement a mailer component.

Config parser's errors are eclipsed

In the event that config.json has an error, such as a trailing comma, the following log is emitted;

Unable to connect to AMQP server: AMQP scheme must be either 'amqp://' or 'amqps://'

This error is (potentially) spurious; the AMQP string may be valid. Likely the JSON parser 's error(s) are being discarded.

Does Let's Encrypt have a Warrant Canary?

http://en.wikipedia.org/wiki/Warrant_canary

That would be pretty great.

Adjust example config to use UDP syslogging

When I follow the instructions in the README (under "A quick-start method for running a Boulder instance is to use one of the example configurations"), docker run fails with the following error:

➜  boulder git:(master) ✗ docker run --name=boulder --read-only=true --rm=true -v $(pwd)/.boulder-config:/boulder:ro -p 4000:4000 quay.io/letsencrypt/boulder:latest boulder  
Could not connect to Syslog: Unix syslog delivery error

Potential timing attack in challenge authentication

https://github.com/letsencrypt/boulder/blob/master/validation-authority.go#L85

This looks like a straightforward classic timing attack. I think you want either http://golang.org/pkg/crypto/subtle/ (ConstantTimeCompare), or some higher-level crypto API, or to make Challenge that higher-level API (implemented with crypto.subtle).

Another approach is to bytes.Compare a randomized form of the tokens (randomized in a way the attacker cannot predict). But since crypto.subtle is there, it seems straightforward to just use that as a drop-in replacement to the current code.

Note that the return values for bytes.Compare and crypto.subtle.ConstantTimeCompare return different values when the arrays are equal. :]

if crypto.subtle.ConstantTimeCompare(body, []byte(challenge.Token)) == 1 {
challenge.Status = StatusValid
return
}

Validate input JWS in RA as well as WFE

Currently the RA trusts the WFE to validate input JWS and provide the correct public key in a NewCertificate request. If the WFE is compromised, and the attacker knows the public key of an account authorized for target site, they could cause issuance for that site by lying to the RA. We should probably pass a copy of the whole request to the RA for secondary validation.

Certificate issuance should block on first OCSP signing

When a new certificate is issued, we need to also sign an OCSP response indicating the certificate is valid and push that response to our OCSP origin server*. We should make sure that this process completes before /certificate/NNN returns the new certificate. Depends on #72.

*we don't need to invalidate cache because certs are requested by serial and there should be no cached response for the new serial, right?

Don't ignore random number generation errors

In

boulder/core/util.go

Line 71 in 81b0d80

func RandomString(byteLength int) string {

:

func RandomString(byteLength int) string {
    b := make([]byte, byteLength)
    rand.Read(b) // NOTE: Ignoring errors
    return B64enc(b)
}

An error in rand.Read might indicate that the system RNG is failing. You probably want to make sure callers hard-fail if there is an error here so that tokens, keys, etc. don't end up with too little entropy.

From https://golang.org/pkg/crypto/rand/#Read:

 On return, n == len(b) if and only if err == nil. 

Assign serial numbers in Boulder-CA

The Boulder-CA instance must be responsible for determining the certificate serial number for a given signing request.

The serial number consists of three parts:

1. A segment ID (8 bits), assigned in the configuration file (to let us distinguish between CA instances)
2. A monotonically increasing identifier (56 bits)
3. Random data (64 bits)

To maintain the monotonically increasing identifier, Boulder-CA should be reworked to use an instance of MariaDB/MySQL, and store the most recently used identifier in a table there. Incrementing that value should be done in a transaction that depends on the successful completion of a signing operation at CFSSL.

Add a protocol version ID to the WFE paths

We need to version the paths in Boulder, such as /v1/acme/....

Send Heartbeats from Activity Monitor

If the Activity Monitor is down, it means we are no longer logging all activity and need to cease operations.

The Activity Monitor should send frequent (1s?) heartbeat messages to AMQP, and each component (but especially the Web Frontend) should consume them. If there is is a pause in Activity Monitor heartbeats, the components should pause their own operations until the Activity Monitor resumes. The Web Frontend should start serving 500s until then.

Maintain a denied database

Our CPS requires that when we deny issuance,

DV-SSL applications that cannot pass this review will not be issued a DV-SSL Certificate. If the DV-SSL Certificate does not pass review, it will be added to a list of previously denied applications and kept for verification purposes of future DV-SSL Certificate applications.

We should add a table to store denied requests.

Is "Expiry" really that unused?

While reading through the implementation, I found that Expiry is marked as not used:

    // Create the remote signer
    localProfile := config.SigningProfile{
        Expiry:       time.Hour, // BOGUS: Required by CFSSL, but not used
        RemoteName:   hostport,  // BOGUS: Only used as a flag by CFSSL
        RemoteServer: hostport,
    }

The cfssl implementation does not support that claim:

• SigningProfile definition.
• FillTemplate setting a default expiry from a profile.
• FillTemplate setting notAfter = notBefore + expiry (if the notAfter date is not set in the profile).

Is this interpretation correct?

Quickstart doesn't fully work

In the Quickstart section there's installation instructions that might not work, depending on your gopath. If you go get github.com/letsencrypt/anvil you don't fetch dependencies for anvil-start, so github.com/codegangsta/cli will be missing.

As anvil-start requires the anvil pkg, changing the go build in the instructions to go get makes sure this dependency is installed, along with whatever the go get of the anvil pkg does.

I'm preparing a pull request.

Handle AMQP disconnection

Currently if there is any interruption of the AMQP server (e.g., it restarts), the various clients will not reconnect. Rather, they each print logs such as:

2015/02/09 22:22:08 [c!] AMQP-RPC timeout [Get]

The clients should detect an RPC timeout and re-subscribe.

Another potential timing attack in challenge authentication

Similar to #17,

boulder/va/validation-authority.go

Line 115 in 8dc0012

if name == zName {

should be a constant-time string comparison. I think the straightforward way to do this in golang is to convert the strings to slices via []byte("foo") and use https://golang.org/pkg/crypto/subtle/#ConstantTimeCompare.

Add test cases for every weird JSON ←→ JWS corner case

JSON is unfortunately not a uniform and deterministic language to parse. Many of the ambiguities in JSON turn into potential attacks against JWS. We need at least one test case to ensure that Boulder's JWS code rejects messages with these ambiguities.

Some known ambiguities are:

• Duplicate keys in a JSON object (we should reject)
• Trailing characters after a valid JSON object (we should reject)
• Numeric types can be parsed to integers or floats (out of caution, we should reject any message containing numerical types)
• Test ignoring of the JWS "Algorithm" field
• Decide whether we're okay with messages containing unknown fields
• Fix go's case insensitivity wrt JSON keys

Non-standard JWK thumbprint computation

JsonWebKey ComputeThumbprint(), used to test for JsonWebKey equality, is non-standard and could potentially cause security issues. For instance, the thumbprint ignores the RSA public exponent value entirely. An attacker who can construct an ECDSA/RSA public key that matches the fingerprint of a registered key of either type can forge JWS signatures for the registered key.

The recommended fingerprint construction according to https://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-01 is:

   the SHA-256 hash of
   the octets of the UTF-8 representation of a JSON object [RFC7159]
   constructed containing only the REQUIRED members of a JWK
   representing the key and with no white space or line breaks before or
   after any syntactic elements and with the REQUIRED members ordered
   lexicographically by the Unicode code points of the member names.

Flaky test

We have a flaky test that fails just some of the time, e.g. https://travis-ci.org/letsencrypt/boulder/builds/59786446:

--- FAIL: TestIssueCertificate (1.19s)
panic: runtime error: slice bounds out of range [recovered]
panic: runtime error: slice bounds out of range

My guess is that the slice in question is the slice that tries to take the first 16 bytes of the hex-encoded serial number. Perhaps the serial number is empty in some random cases? Could be related to timing issues with regards to the certificate authority's sequence DB?

Limit account registrations & domain validations

Boulder needs to be able to limit the number of active accounts and validated domains, to let us slow-roll startup.

The administrators will want to be able to change the limits regularly, constantly and in an automated fashion. I think this should be done as a database table, so that it is persistent and up-datable.

I recommend writing the module to check for the existence of a table named Quotas and, if it exists, only permit a particular action if there is remaining quota, decrementing the quota as it does.

Schema idea:

CREATE TABLE Quota (id INTEGER, type VARCHAR(32), available INTEGER)

types:

• accountRegistration
• domainRegistration
• certificateIssuance

We can then write simple test scripts that add 10 to "available" for each type, for example, to run when desired.

Handle SIGTERM gracefully

When receiving SIGTERM, Boulder instances should:

1. Immediately stop reading any messages on the AMQP interface
2. Finish processing any outstanding messages
3. Close

This lets us do rolling restarts without data loss.

Catching SIGTERM seems well-understood with the os/signal package. Just look for syscall.SIGTERM and set appropriate flags in motion.

Noteworthy StackOverflow:
http://stackoverflow.com/questions/11268943/golang-is-it-possible-to-capture-a-ctrlc-signal-and-run-a-cleanup-function-in

Whitelist values to copy from CSR

CSR is a powerful format and allows specifying arbitrary extensions. Since the user fully controls CSR input, we want to strictly whitelist which values from the CSR can be copied into the certificate. It probably makes sense to implement this in CFSSL rather than Boulder. CFSSL issue cloudflare/cfssl#156 has some of the discussion.

/new-cert should 201 to /certificate

To match the spec. I'll work on this today - most of the parts are in place already.

Use Policy Database for decisions

Files like psl.go and blacklist.go will require regular recompiles of boulder; it'll be better to be able to feed updated config files or databases (we'll need the latter for the set of valid cert names) into a running boulder instance.

Wildcard Certificate Support

According to a presentation by Seth Schoen and according to brief inspection of the CA source code, Let's Encrypt is planning on not issuing wildcard certificates. IIRC, the reason given by Schoen was the lack of a method of checking that the ACME client really speaks for the whole domain subspace. Furthermore, it was observed that being able to quickly meant non-wildcard certificates for a particular host names in an automated fashion without payment makes wildcard certificates less necessary.

This doesn't address the wildcard use case that Sandstorm (https://sandstorm.io/) has: Minting randomly-generated host names all the time in order to generate new unguessable origins. In order for newly-minted origins to work immediately, it doesn't make sense to wait even for fast automatic certificate issuance. Also, I would imagine that as long as the Baseline Requirements don't exempt short-lived certificates from revocation infrastructure requirements, Let's Encrypt might not be too keen to have servers generate certs for throw-away hostnames all the time.

To address this use case, I suggest that Let's Encrypt issues a wildcard certificate when the ACME client can demonstrate that it speaks for several hostnames that are randomly generated by the Registration Authority. For some reasonable value for "several", the RA should be able to convince itself that there exists a DNS wildcard that makes hostnames that would match the requested wildcard certificates point to the server running the ACME client.

Why AMQP for RPC?

The version of amqp that you're using is good but it's dead, because there is a 1.0 version which is seriously made and everyone using that should be executed on site. So why use the dead protocol version amqp 0.9.1?

WFE should look up account key before any processing

WFE should be able to check whether a given account key exists in the system before doing any further parsing or passing data to any backends.

Log consistently using Syslog over TCP

For central logging we will want to reduce the use of stdout / stderr and prefer RFC 5424 syslogging over TCP. Logging should follow a consistent format so that we can write a Logstash grok rule to decode important details.

The remote logging server should be specified by hostname via the command line.

It appears that the Go syslog package supports syslog over UDP and TCP.

CFSSL must accept serial numbers in signing requests

CFSSL currently generates wholly-random serial numbers. For Issue #83, we want to pass in a serial number.

Create and land a patch for CFSSL to support sending it as part of the signing request message.

Some endpoints in web-front-end.go need to check for key continuity

NewAuthorization and NewCertificate in web-front-end.go call verifyPost but don't check that the verifying key is the one that has been registered.

Load testing

We should implement a load testing framework for Boulder and test it thoroughly.

Audit Logging

All of the following are identified as audit log entries that must be produced by Boulder. These must be written with the AuditLogger.Audit() function from PR #61.
These are valid as of CPS draft 2.1, updates for 4/1/2015.

All Certificate requests – Date and time of request, type of event, and request information are automatically logged by the application. This includes Issuance, renewal, and re-key requests as well as sender/requester DN, Certificate serial number, initial application, method of request (online, in-person), source of verification, name of document presented for identity proofing, all fields verified in the application, Certificate common name, new validity period dates, date and time of response and success or failure indication are automatically logged by the application, and all associated error messages and codes. Manual interactions with participants such as telephone or in person inquiries and results of verification calls will be logged manually in a logbook or in a computer-based recording/tracking system and include date/time, description of interaction and identity provided.

All Certificate Revocation requests – Date and time of Revocation request, sender/requester DN, Certificate serial number, subject DN of Certificate to revoke, Subscriber’s common name, Revocation reason, date and time of response and success or failure indication are automatically logged by the application; manual interactions with requestors such as telephone or in person inquiries and requests for Revocation are logged manually in a logbook or in a computer-based recording/tracking system. The date/time, description of interaction and identity provided are also recorded.

The approval or rejection of a Certificate status change request – Identity of equipment operator who initiated the request, message contents, message source, destination, and success or failure indication are automatically logged by the application.

Any security-relevant changes to the configuration of a component – Date and time of modification, name of modifier, description of modification, build information (i.e. size, version number) of any modified files and the reason for modification are manually logged during change management processes.

All Certificate compromise notification requests – Date and time of notification, identity of person making the notification, identification of entity compromised, and a description of the compromise are logged manually by the personnel who receive the notification (e.g. Help Desk, RA Operators, etc.) and by RA/RA Operators’ system processing logs.

Software error conditions – Date and time of event, and description of event are automatically logged by the application reporting the event or by the operating system.

Software check integrity failures – Date and time of event, and description of event are automatically logged by the application reporting the event or by the operating system.

Receipt of improper messages – Date and time of event, and description of event are automatically logged by the application reporting the event or by the operating system.

Misrouted messages – Date and time of event, and description of event are automatically logged by the application reporting the event or by the operating system.

Support relational databases in Boulder-CA

Update configuration and object construction to have access to a database in the Boulder CA module. Required for Issue #83.

Rate limiting

The WFE should be able to do rate limiting by:

• Client IP address
• Account key
• 2LD (i.e. the first label after a public suffix)
• global account count (for beta deployment)
• global validated domain count (for beta deployment)
• global cert count (for beta deployment)

These rate limits should be readily adjustable with a config file, and should be overridable for specific values of each rate limit key.