This makes the log events easier to parse, and makes it easier to
consistently use the correct fields from the issuance request.
Also, reduce the number of fields that are logged on error events.
Logging just the serial and the error in most cases should suffice to
cross-reference the error with the item that we attempted to sign.
One downside is that this increases the total log size (10kB above, vs
7kB from a similar production issuance) due in part to more repetition.
For example, both the "signing cert" and "signing cert success" log
lines include the full precert DER.
Note that our long-term plan for more structured logs is to have a
unique event id to join logs on, which can avoid this repetition. But
since we don't currently have convenient ways to do that join, some
duplication (as we currently have in the logs) seems reasonable.
One format we receive key compromise reports is as a CSR file. For
example, from https://pwnedkeys.com/revokinator
This allows the admin command to block a key from a CSR directly,
instead of needing to validate it manually and get the SPKI or key from
it.
I've added a flag (default true) to check the signature on the CSR, in
case we ever decide we want to block a key from a CSR with a bad
signature for whatever reason.
TestTraces is designed to test whether our Open Telemetry tracing system
is working: that spans are being output, that they have the appropriate
parents, etc. It should not be testing whether Boulder took a specific
path through its code -- that's the domain of package-specific unit
tests. Simplify TestTraces to the point that it is asserting (nearly)
the bare minimum about the set of operations Boulder performs.
Add a new method, `BatchIncrement`, to issue `IncrBy` (instead of `Set`)
to Redis. This helps prevent the race condition that allows bursts of
near-simultaneous requests to, effectively, spend the same token.
Call this new method when incrementing an existing key. New keys still
need to use `BatchSet` because Redis doesn't have a facility to, within
a single operation, increment _or_ set a default value if none exists.
Add a new feature flag, `IncrementRateLimits`, gating the use of this
new method.
CPS Compliance Review: This feature flag does not change any behaviour
that is described or constrained by our CP/CPS. The closest relation
would just be API availability in general.
Fixes#7780
The naming of our `precertificates` table (now used to store linting
certificates) is definitely confusing, so add some more comments in
various places explaining. See #6807.
Bumps the aws group with 3 updates in the / directory:
[github.com/aws/aws-sdk-go-v2](https://github.com/aws/aws-sdk-go-v2),
[github.com/aws/aws-sdk-go-v2/config](https://github.com/aws/aws-sdk-go-v2)
and
[github.com/aws/aws-sdk-go-v2/service/s3](https://github.com/aws/aws-sdk-go-v2).
Updates `github.com/aws/aws-sdk-go-v2` from 1.31.0 to 1.32.2
Updates `github.com/aws/aws-sdk-go-v2/config` from 1.27.39 to 1.27.43
Updates `github.com/aws/aws-sdk-go-v2/service/s3` from 1.63.3 to 1.65.3
Updates `github.com/aws/smithy-go` from 1.21.0 to 1.22.0
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Creating the list of authzIDs earlier in NewOrderAndAuthzs:
- Saves a `for` loop with duplicated code; we no longer need to range
over two different slices, just one.
- Allows us to create the Order PB later, after more of the data
collection logic, without interrupting it. This makes the order of
operations slightly easier to follow.
- Add `Perspective` and `RIR` fields to the remote-va configuration
- Configure RVA ValidationAuthorityImpl instances with the contents of
the JSON configuration
- Configure VA ValidationAuthorityImpl instances with the constant
`va.PrimaryPerspective`
- Log `Perspective` for non-Primary Perspectives, per the MPIC
requirements in section 5.4.1 (2) vii of the BRs. Also log the RIR for
posterity.
- Introduce `ValidationResult` RPC fields `Perspective` and `Rir`, which
are not currently used but will be required for corroboration in #7616
Fixes https://github.com/letsencrypt/boulder/issues/7613
Part of https://github.com/letsencrypt/boulder/issues/7615
Part of https://github.com/letsencrypt/boulder/issues/7616
Initialize a slice with a capacity of len(nameToString) rather than initializing
the length of this slice.
Signed-off-by: huochexizhan <huochexizhan@outlook.com>
Updates:
- go.opentelemetry.io/contrib/instrumentation (and subpackages) from 0.52.0 to 0.55.0
- go.opentelemetry.io/otel (and subpackages) from 1.27.0 to 1.30.0
Upstream release notes:
https://github.com/open-telemetry/opentelemetry-go-contrib/releases
Also transitively updates a few golang.org/x/ dependencies, and the grpc and protobuf
dependencies.
This config field duplicates functionality that is better provided by
the blockedKeys database table. We should only have one mechanism for
blocking keys, so this one should be removed.
Mark it deprecated as a warning to any downstream consumers of Boulder.
Part of https://github.com/letsencrypt/boulder/issues/7748
The CAB/F Debian weak keys (https://github.com/cabforum/Debian-weak-keys)
repository contains a bunch of DER encoded private keys that we should ensure
are blocked. I hacked up the block-a-key tool to output a base64 encoded SPKI
hash from an arbitrary PEM formatted private key file.
This is our only use of MariaDB's "INSERT ... RETURNING" syntax, which
does not exist in MySQL and Vitess. Add a feature flag which removes our
use of this feature, so that we can easily disable it and then re-enable
it if it turns out to be too much of a performance hit.
Also add a benchmark showing that the serial-insertion approach is
slower, but perhaps not debilitatingly so.
Part of https://github.com/letsencrypt/boulder/issues/7718
Previously, we logged csr.DNSNames along with the precertificate
issuance events, but this was potentially misleading. For instance, if a
CSR contained only a CN and no SANs, this set would be empty.
Instead, log the uniquified, lowercased, sorted SANs that are actually
issued.
Also, emit precert=[] in issuePrecertificateInner, which is consistent
with the field name used when the final certificate is issued.
Note: this definitely underscores why it would be better to log these
things in a more structured way, for instance logging the
`issuance.IssuanceRequest` encoded as JSON, but I wanted to get these
quick fixes out of the way first.
Add a new SerialPrefixHex field to the CA's config, which takes a
two-character hexadecimal string to use as the serial prefix. This
matches the way that the OCSP Responder's acceptable serial prefixes are
configured, and is easier for human operators to configure than raw
integers.
At the same time, change the type of the CA's internal serial prefix
from `int` to `byte`, using the type system to enforce its 8-bit length.
Fixes#7213
This adds custom spans around one of the more important parts of the
issuance stack - actually signing the (pre)certificates. We only have
automatic tracing right now, so this is just a small step towards adding
more customization there.
One specific note: I didn't include the regID in the span attributes,
though it is in the nearby log lines. I think that's something we likely
want to handle holistically (eg, via baggage propagation) rather than
one-off in manual spans like this.
The Boulder WFE accepts incoming connections (from our load balancers)
via either TLS or plain HTTP. When those connections are made over TLS,
it already enforces that the client be using TLS 1.3 or above. When those
connections are made over plain HTTP, the load balancer includes the TLS
version as a header, and Boulder was performing filtering based on that.
Our load balancers are now configured to reject older TLS versions, so we
can remove this check.
Fixes https://github.com/letsencrypt/boulder/issues/7710
The intention here should be to initialize a slice with a capacity of
len(remaining) rather than initializing the length of this slice, so that
the resulting error message doesn't start with empty-string entries.
OpenTelemetry has "semantic conventions" which are versioned
independently of the software package, as it describes the semantics of
the resources being produced. Previously, we'd combined
`resource.Default()` using the `Merge` function with our own resources.
Merge, however, doesn't handle merging resources with different semantic
conventions. This means that every dependabot PR that bumps otel will
break when the `resources.Default` has a new version.
That doesn't seem worth it for the default resources, so just provide
our own resources which have everything we care about. I've added the
PID which we didn't have before but will be interesting. We will lose
the SDK's version, but I don't think that matters.
For more discussion on this topic, see
https://github.com/open-telemetry/opentelemetry-go/issues/3769
Jacob Hoffman-Andrews