Module filter 

Request filtering: named checks, boolean rules over them, and the machinery that turns a request into one answer.

Filters answer a different question from challenge: who may ask, rather than whether they control the name. Both matter, and when challenge.bypass is on, filtering is the only thing deciding who may obtain a certificate, because a triggered challenge is then accepted with no network check at all.

The shape

A Check is one named question — “is this address in the management network?”, “does the inventory say this address owns this name?” — declared as [filter.check.<name>] with a type. A rule is a boolean expression over check names plus what a match means, declared as [filter.rule.<name>] and selected and ordered by filter.rules. FilterPolicy holds both and answers one request.

[filter]
rules = ["mgmt-bypass", "inventory-owned"]

[filter.check.mgmt-net]
type  = "allowed_ip"
allow = ["10.0.0.0/8"]

[filter.check.inventory]
type = "ipam"

[filter.rule.mgmt-bypass]
when = "mgmt-net"
then = "allow"

[filter.rule.inventory-owned]
when = "inventory or mgmt-net"
then = "allow"

Everything is a named check: custom is type = "custom" like any other, with no separate selection list of its own, and two instances of one type are ordinary rather than impossible.

Two hook points

Some checks decide from the connection alone (is this IP allowed? does it have a valid PTR record?); others need the names being requested, which only the handlers know. Rather than two traits, Check has two methods, both defaulting to “pass”:

• check_connection runs in add_filter_middleware for every request.
• check_identifiers runs at newOrder (the order’s identifiers) and again at finalize (the CSR’s subject alternative names and common name).

Which rules run at which hook, and why the answer is an intersection rather than a union, is policy’s subject.

Startup validation

CIDRs, regexes and conditions are parsed once in from_config, which returns an anyhow::Error the binary treats as fatal. A typo in a netmask is a configuration bug that should stop the server, not silently deny (or admit) traffic at runtime.

Re-exports

pub use client_ip::ClientIp;

pub use client_ip::ProxyPolicy;

pub use eab::EabIdentity;

pub use policy::Check;

pub use policy::CheckSummary;

pub use policy::Effect;

pub use policy::FilterPolicy;

pub use policy::Mode;

pub use policy::Outcome;

pub use policy::Rule;

pub use policy::RuleSummary;

pub use policy::Stage;

pub use policy::StageSet;

pub use policy::Verdict;

Modules

build

Turning [filter] into a FilterPolicy.

client_ip

Deciding which address a request actually came from.

custom

The custom check: executes an external script/binary to evaluate requests.

eab

The eab check: which credential the account was registered under.

explain

Rendering a policy, and what it would do to one hypothetical request.

expr

The condition language a [filter.rule.<name>] is written in.

identifiers

The identifiers filter: which names a client may have certified.

ip_allow

The allowed_ip check: which networks may talk to the server.

ipam

The ipam filter: the client’s address must own the names it asks for.

path

The path check: which request paths a rule applies to.

policy

The policy engine: named checks, boolean rules over them, and the evaluator.

reverse_dns

The reverse_dns filter: the client’s address must have a usable PTR record.

Structs

ConnectionContext

What a Check knows about a request before it is dispatched.

IdentifierContext

What a Check knows about the names a client wants certified.

Enums

IdentifierStage

Where in the flow a set of identifiers is being checked.

Functions

from_config

Builds the configured policy. Called once at startup, so it may fail fast (the caller exits on error).