github.com/letsencrypt/boulder@v0.20251208.0/docs/multi-va.md (about)

     1  # Multi-VA implementation
     2  
     3  Boulder supports a multi-perspective validation feature intended to increase
     4  resilience against local network hijacks and BGP attacks. It is currently
     5  [deployed in a production
     6  capacity](https://letsencrypt.org/2020/02/19/multi-perspective-validation.html)
     7  by Let's Encrypt.
     8  
     9  If you follow the [Development Instructions](https://github.com/letsencrypt/boulder#development)
    10  to set up a Boulder environment in Docker and then change your `docker-compose.yml`'s
    11  `BOULDER_CONFIG_DIR` to `test/config-next` instead of `test/config` you'll have
    12  a Boulder environment configured with two primary VA instances (validation
    13  requests are load balanced across the two) and two remote VA instances (each
    14  primary VA will ask both remote VAs to perform matching validations for each
    15  primary validation). Of course this is a development environment so both the
    16  primary and remote VAs are all running on one host.
    17  
    18  The `boulder-va` service ([here](https://github.com/letsencrypt/boulder/tree/main/cmd/boulder-va) and `remoteva` service ([here](https://github.com/letsencrypt/boulder/tree/main/cmd/remoteva)) are distinct pieces of software that utilize the same package ([here](https://github.com/letsencrypt/boulder/tree/main/va)).
    19  The boulder-ra uses [the same RPC interface](https://github.com/letsencrypt/boulder/blob/ea231adc36746cce97f860e818c2cdf92f060543/va/proto/va.proto#L8-L10)
    20  to ask for a primary validation as the primary VA uses to ask a remote VA for a
    21  confirmation validation.
    22  
    23  Primary VA instances contain a `"remoteVAs"` configuration element. If present
    24  it specifies gRPC service addresses for `remoteva` instances to use as remote
    25  VAs. There's also a handful of feature flags that control how the primary VAs
    26  handle the remote VAs.
    27  
    28  In the development environment with `config-next` the two primary VAs are `va1.service.consul:9092` and
    29  `va2.service.consul:9092` and use
    30  [`test/config-next/va.json`](https://github.com/letsencrypt/boulder/blob/ea231adc36746cce97f860e818c2cdf92f060543/test/config-next/va.json)
    31  as their configuration. This config file specifies two `"remoteVA"s`,
    32  `rva1.service.consul:9097` and `va2.service.consul:9098` and enforces
    33  [that a maximum of 1 of the 2 remote VAs disagree](https://github.com/letsencrypt/boulder/blob/ea231adc36746cce97f860e818c2cdf92f060543/test/config-next/va.json#L44)
    34  with the primary VA for all validations. The remote VA instances use
    35  [`test/config-next/remoteva-a.json`](https://github.com/letsencrypt/boulder/blob/5c27eadb1db0605f380e41c8bd444a7f4ffe3c08/test/config-next/remoteva-a.json)
    36  and
    37  [`test/config-next/remoteva-b.json`](https://github.com/letsencrypt/boulder/blob/5c27eadb1db0605f380e41c8bd444a7f4ffe3c08/test/config-next/remoteva-b.json)
    38  as their config files.
    39  
    40  We require that almost all remote validation requests succeed; the exact number
    41  is controlled by the VA based on the thresholds required by MPIC. If the number of
    42  failing remote VAs exceeds that threshold, validation is terminated. If the
    43  number of successful remote VAs is high enough that it would be impossible for
    44  the outstanding remote VAs to exceed that threshold, validation immediately
    45  succeeds.
    46  
    47  There are some integration tests that test this end to end. The most relevant is
    48  probably
    49  [`test_http_multiva_threshold_fail`](https://github.com/letsencrypt/boulder/blob/ea231adc36746cce97f860e818c2cdf92f060543/test/v2_integration.py#L876-L908).
    50  It tests that a HTTP-01 challenge made to a webserver that only gives the
    51  correct key authorization to the primary VA and not the remotes will fail the
    52  multi-perspective validation.