Proto commits in letsencrypt/boulder

These commits are when the Protocol Buffers files have changed: (only the last 100 relevant commits are shown)

2025-05-08

sa: Store and manage rate limit overrides in the database (#8142) Add support for managing and querying rate limit overrides in the database. - Add `sa.AddRateLimitOverride` to insert or update a rate limit override. This will be used during Rate Limit Override Portal to commit approved overrides to the database. - Add `sa.DisableRateLimitOverride` and `sa.EnableRateLimitOverride` to toggle override state. These will be used by the `admin` tool. - Add `sa.GetRateLimitOverride` to retrieve a single override by limit enum and bucket key. This will be used by the Rate Limit Portal to prevent duplicate or downgrade requests but allow upgrade requests. - Add `sa.GetEnabledRateLimitOverrides` to stream all currently enabled overrides. This will be used by the rate limit consumers (`wfe` and `ra`) to refresh the overrides in-memory. - Implement test coverage for all new methods.

The documentation is generated from this commit.

ra, va: Bypass CAA for IP identifiers & use Identifier in IsCAAValidRequest (#8153) In `vapb.IsCAAValidRequest`, even though CAA is only for DNS names, deprecate `Domain` in favour of `Identifier` for consistency. In `va.DoCAA`, reject attempts to validate CAA for non-DNS identifiers. Rename `identifier` to `ident` inside some VA functions, also for consistency. In `ra.checkDCVAndCAA` & `ra.checkAuthorizationsCAA`, bypass CAA checks for IP address identifiers. Part of #7995

2025-05-07

va: Use Identifier in IsCAAValidRequest Even though CAA is only for DNS names, deprecate `Domain` in favour of `Identifier` for consistency. In `DoCAA`, reject attempts to validate CAA for non-DNS identifiers. Rename `identifier` to `ident` inside some VA functions, also for consistency.

ra: Fully support identifiers in NewOrder, PerformValidation & RevokeCertByApplicant (#8139) In `ra.NewOrder`, improve safety of authz reuse logic by making it explicit that only DNS identifiers might be wildcards. Also, now that the conditional statements need to be more complicated, collapse them for brevity. In `vapb.PerformValidationRequest`, remove `DnsName`. In `ra.PerformValidation`, pass an `Identifier` instead of a `DnsName`. In `ra.RevokeCertByApplicant`, check that the requester controls identifiers of all types (not just DNS). Fixes #7995 (the RA now fully supports IP address identifiers, except for rate limits) Fixes #7647 Part of #8023

2025-05-05

Addressing comments.

2025-05-02

Remove DnsName from vapb.PerformValidationRequest

va: Use Identifier in IsCAAValidRequest Even though CAA is only for DNS names, deprecate `Domain` in favour of `Identifier` for consistency. In `DoCAA`, reject attempts to validate CAA for non-DNS identifiers. Rename `identifier` to `ident` inside some VA functions, also for consistency.

2025-05-01

va: Use Identifier in IsCAAValidRequest Even though CAA is only for DNS names, deprecate `Domain` in favour of `Identifier` for consistency. In `DoCAA`, reject attempts to validate CAA for non-DNS identifiers. Rename `identifier` to `ident` inside some VA functions, also for consistency.

Remove DnsName from vapb.PerformValidationRequest

2025-04-24

sa: Rate limit overrides in the database

2025-04-23

sa: Rate limit overrides in the database

2025-04-18

ca: remove capb.IssueCertificateForPrecertificateRequest (#8127) Fixes #8039

2025-04-17

Remove capb.IssueCertificateForPrecertificateRequest

2025-04-11

ca: Remove IssuePrecertificateResponse (#8115) Instead, simply return DER bytes from `issuePrecertificate`, and accept regular parameters to `issueCertificateForPrecertificate` (instead of a proto message). Also, move the lookup of the certificate profile up to `IssueCertificate`, and pass the selected `*certProfileWithId` to both `issuePrecertificate` and `issueCertificateForPrecertificate`. Also, change `issueCertificateForPrecertificate` to just return DER, not a `*corepb.Certificate` (of which most fields were already being ignored).

2025-04-10

sa: Support new identifier types in authz getting funcs (#8104) Refactor `GetAuthorizations2`, `GetValidAuthorizations2` and `GetValidOrderAuthorizations2` to support non-DNS identifier types. Remove the deprecated `DnsNames` field from the `GetAuthorizationsRequest` and `GetValidAuthorizationsRequest` structs. All users of these structs use `Identifier` instead. Fixes #7922 Part of #7311

2025-04-08

core: Remove DnsNames from Order (#8108) Remove the deprecated `DnsNames` field from the `corepb.Order` proto message. All users of this struct use `Identifiers` instead. This unblocks future changes that will require `Order` users to handle different identifier types. Part of #7311

sa: Remove DnsNames from more request protos (#8105) Remove the deprecated `DnsNames` field from the `CountFQDNSetsRequest`, `FQDNSetExistsRequest`, and `GetOrderForNamesRequest` structs. All users of these structs use `Identifier` instead. Part of #7311

sa: Remove DnsNames from NewOrderRequest (#8101) Remove the deprecated `DnsNames` field from the `NewOrderRequest` struct. All users of this struct use `Identifier` instead. Part of #7311

sa: Support IP identifiers in CountInvalidAuthorizations2 (#8098) Remove the deprecated `DnsName` field from the `CountInvalidAuthorizationsRequest` struct. All users of this struct use `Identifier` instead. Part of #7311

ra: Remove DnsNames from NewOrderRequest (#8100) Remove the deprecated `DnsNames` field from the `NewOrderRequest` struct. All users of this struct use `Identifier` instead. Part of #7311

2025-04-07

core: Remove DnsName from Authorization (#8097) Remove the deprecated `DnsName` field from the core `Authorization` struct. All users of this struct use `Identifier` instead. This unblocks future changes that will require `Authorization` users to handle different identifier types. Part of #7311

2025-04-03

ca: unexport IssuePrecertificate and IssueCertificateForPrecertificate (#8092) These methods are still preserved as-is for now, and still take proto messages as arguments. But they are not exported as RPCs. Refactoring the arguments will be a followup PR. Part of #8039

2025-03-26

Add Identifiers to Authorization & Order structs (#7961) Add `identifier` fields, which will soon replace the `dnsName` fields, to: - `corepb.Authorization` - `corepb.Order` - `rapb.NewOrderRequest` - `sapb.CountFQDNSetsRequest` - `sapb.CountInvalidAuthorizationsRequest` - `sapb.FQDNSetExistsRequest` - `sapb.GetAuthorizationsRequest` - `sapb.GetOrderForNamesRequest` - `sapb.GetValidAuthorizationsRequest` - `sapb.NewOrderRequest` Populate these `identifier` fields in every function that creates instances of these structs. Use these `identifier` fields instead of `dnsName` fields (at least preferentially) in every function that uses these structs. When crossing component boundaries, don't assume they'll be present, for deployability's sake. Deployability note: Mismatched `cert-checker` and `sa` versions will be incompatible because of a type change in the arguments to `sa.SelectAuthzsMatchingIssuance`. Part of #7311

2025-03-14

Return updated account object on DeactivateRegistration path (#8060) Update the SA to re-query the database for the updated account after deactivating it, and return this to the RA. Update the RA to pass this value through to the WFE. Update the WFE to return this value, rather than locally modifying the pre-deactivation account object, if it gets one (for deployability). Also remove the RA's requirement that the request object specify its current status so that the request can be trimmed down to just an ID. This proto change is backwards-compatible because the new DeactivateRegistrationRequest's registrationID field has the same type (int64) and field number (1) as corepb.Registration's id field. Part of https://github.com/letsencrypt/boulder/issues/5554

2025-03-12

ARI: Store and reflect optional "replaces" value for Orders (#8056) - Plumb the "replaces" value from the WFE through to the SA via the RA - Store validated "replaces" value for new orders in the orders table - Reflect the stored "replaces" value to subscribers in the order object - Reorder CertificateProfileName before Replaces/ReplacesSerial in RA and SA protos for consistency Fixes #8034

2025-03-06

va: Support IP address identifiers (#8020) Add an `identifier` field to the `va.PerformValidationRequest` proto, which will soon replace its `dnsName` field. Accept and prefer the `identifier` field in every VA function that uses this struct. Don't (yet) assume it will be present. Throughout the VA, accept and handle the IP address identifier type. Handling is similar to DNS names, except that `getAddrs` is not called, and consider that: - IPs are represented in a different field in the `x509.Certificate` struct. - IPs must be presented as reverse DNS (`.arpa`) names in SNI for [TLS-ALPN-01 challenge requests](https://datatracker.ietf.org/doc/html/rfc8738#name-tls-with-application-layer-). - IPv6 addresses are enclosed in square brackets when composing or parsing URLs. For HTTP-01 challenges, accept redirects to bare IP addresses, which were previously rejected. Fixes #2706 Part of #7311

2025-03-05

email/exporter: Add email.Exporter gRPC service (#8017) Initial implementation of the email.Exporter gRPC service to be used by the new cmd/email-exporter. Part of #7966

2025-03-03

va/ra: Deprecate EnforceMultiCAA and EnforceMPIC (#8025) Replace DCV and CAA checks (PerformValidation and IsCAAValid) in va/va.go and va/caa.go with their MPIC compliant counterparts (DoDCV and DoCAA) in va/vampic.go. Deprecate EnforceMultiCAA and EnforceMPIC and default code paths as though they are both true. Require that RIR and Perspective be set for primary and remote VAs. Fixes #7965 Fixes #7819

2025-02-24

ca: unsplit issuance flow (#8014) Add a new RPC to the CA: `IssueCertificate` covers issuance of both the precertificate and the final certificate. In between, it calls out to the RA's new method `GetSCTs`. The RA calls the new `CA.IssueCertificate` if the `UnsplitIssuance` feature flag is true. The RA had a metric that counted certificates by profile name and hash. Since the RA doesn't receive a profile hash in the new flow, simply record the total number of issuances. Fixes https://github.com/letsencrypt/boulder/issues/7983

2025-02-19

Prospect(s) -> Contact(s)

2025-02-14

Merge remote-tracking branch 'origin/main' into add-email-exporter

2025-02-13

crl: add cache control headers (#8011) The crl-storer passes along Cache-Control and Expires from the crl-updater (because the crl-updater knows the UpdatePeriod). The crl-updater calculates the Expires header based on when it expects to update the CRL, plus a margin of error. Fixes #8004

2025-02-12

Adjust proto.

2025-02-07

email: Initial Exporter implementation

2025-02-03

RA: Don't reuse authzs with mismatched profiles (#7967) In the RA, inspect the profile of all authorizations returned when looking for authz reuse, and refuse to reuse any whose profile doesn't match the requested profile of the current NewOrder request. Fixes https://github.com/letsencrypt/boulder/issues/7949

2025-01-27

SA: Support profiles associated with authorizations (#7956) Add "certificateProfileName" to the model used to insert new authz2 rows and to the list of column names read when retrieving rows from the authz2 table. Add support for this column to the functions which convert to and from authz2 model types. Add support for the profile field to core types so that it can be returned by the SA. Fixes https://github.com/letsencrypt/boulder/issues/7955

2025-01-26

core: Remove contactsPresent from Registration (#7952) Remove the `contactsPresent` field from `corepb.Registration`, and all places where it is set. #7933 removed all places where it was used. Fixes #7920

2025-01-22

sa: add GetRevokedCertsByShard (#7946) The SA had some logic (not yet in use) to return revoked certificates either by temporal sharding (if `req.ShardIdx` is zero) or by explicit sharding (if `req.ShardIdx` is nonzero). This PR splits the function into two. The existing `GetRevokedCerts` always does temporal sharding. The new `GetRevokedCertsByShard` always does explicit sharding. Eventually only `GetRevokedCertsByShard` will be necessary. This change was discussed in https://github.com/letsencrypt/boulder/issues/7094#issuecomment-2587940962 and is a precursor to having the crl-updater call both methods, so we can merge the results when generating CRLs.

ra: revoke with explicit CRL shard (#7944) In RA.RevokedCertificate, if the certificate being revoked has a crlDistributionPoints extension, parse the URL and pass the appropriate shard to the SA. This required some changes to the `admin` tool. When a malformed certificate is revoked, we don't have a parsed copy of the certificate to extract a CRL URL from. So, specifically when a malformed certificate is being revoked, allow specifying a CRL shard. Because different certificates will have different shards, require one-at-a-time revocation for malformed certificates. To support that refactoring, move the serial-cleaning functionality earlier in the `admin` tool's flow. Also, split out one of the cases handled by the `revokeCertificate` helper in the RA. For admin malformed revocations, we need to accept a human-specified ShardIdx, so call the SA directly in that case (and skip stat increment since admin revocations aren't useful for metrics). This allows `revokeCertificate` to be a more helpful helper, by extracting serial, issuer ID, and CRL shard automatically from an `*x509.Certificate`. Note: we don't yet issue certificates with the crlDistributionPoints extension, so this code will not be active until we start doing so. Part of #7094.

2025-01-21

WIP

2025-01-14

ra/sa: Remove deprecated UpdateRegistration methods (#7911) This is the final stage of #5554: removing the old, combined `UpdateRegistration` flow, which has been replaced by `UpdateRegistrationContact` and `UpdateRegistrationKey`. Those new functions have their own tests. The RA's `UpdateRegistration` function no longer has any callers (as of #7827's deployment), so it is safely deployable to remove it from the SA too, and its request from gRPC. Fixes #5554 --------- Co-authored-by: Jacob Hoffman-Andrews <jsha+github@letsencrypt.org> Co-authored-by: Aaron Gable <aaron@letsencrypt.org>

2025-01-13

database: No longer store or retrieve InitialIP (#7942) The initialIP column has been defaulted to 0.0.0.0 since #7760. Remove this field from the all structs while leaving the schema itself intact. Part of #7917

ra: Remove isRenewal & isARIRenewal from NewOrderRequest proto (#7932) Fixes #7671 Fixes #5545

2025-01-10

Deprecate DisableLegacyLimitWrites & UseKvLimitsForNewOrder flags; remove code using certificatesPerName & newOrdersRL tables (#7858) Remove code using `certificatesPerName` & `newOrdersRL` tables. Deprecate `DisableLegacyLimitWrites` & `UseKvLimitsForNewOrder` flags. Remove legacy `ratelimit` package. Delete these RA test cases: - `TestAuthzFailedRateLimitingNewOrder` (rl: `FailedAuthorizationsPerDomainPerAccount`) - `TestCheckCertificatesPerNameLimit` (rl: `CertificatesPerDomain`) - `TestCheckExactCertificateLimit` (rl: `CertificatesPerFQDNSet`) - `TestExactPublicSuffixCertLimit` (rl: `CertificatesPerDomain`) Rate limits in NewOrder are now enforced by the WFE, starting here: https://github.com/letsencrypt/boulder/blob/5a9b4c4b18fd0aa670bc6332bdd59701ff7d6186/wfe2/wfe.go#L781 We collect a batch of transactions to check limits, check them all at once, go through and find which one(s) failed, and serve the failure with the Retry-After that's furthest in the future. All this code doesn't really need to be tested again; what needs to be tested is that we're returning the correct failure. That code is `NewOrderLimitTransactions`, and the `ratelimits` package's tests cover this. The public suffix handling behavior is tested by `TestFQDNsToETLDsPlusOne`: https://github.com/letsencrypt/boulder/blob/5a9b4c4b18fd0aa670bc6332bdd59701ff7d6186/ratelimits/utilities_test.go#L9 Some other RA rate limit tests were deleted earlier, in #7869. Part of #7671.

2024-12-19

sa: add Limit field to CountFQDNSetsRequest (#7887) This allows us to replace FQDNSetExists with a call to FQDNSetTimestampsForWindow, with Limit set to 1. That, in turn, will allow us to log the time since issuance of the most recent certificate with a given FQDNSet.

2024-12-16

sa: remove CountFQDNSetTimestamps (#7883) This was superseded in #6220 by FQDNTimestampsForWindow and is no longer called.

2024-12-10

RA/VA: Add MPIC compliant DCV and CAA checks (#7870) Today, we have VA.PerformValidation, a method called by the RA at challenge time to perform DCV and check CAA. We also have VA.IsCAAValid, a method invoked by the RA at finalize time when a CAA re-check is necessary. Both of these methods can be executed on remote VA perspectives by calling the generic VA.performRemoteValidation. This change splits VA.PerformValidation into VA.DoDCV and VA.DoCAA, which are both called on remote VA perspectives by calling the generic VA.doRemoteOperation. VA.DoDCV, VA.DoCAA, and VA.doRemoteOperation fulfill the requirements of SC-067 V3: Require Multi-Perspective Issuance Corroboration by: - Requiring at least three distinct perspectives, as outlined in the "Phased Implementation Timeline" in BRs section 3.2.2.9 ("Effective March 15, 2025"). - Ensuring that the number of non-corroborating (failing) perspectives remains below the threshold defined by the "Table: Quorum Requirements" in BRs section 3.2.2.9. - Ensuring that corroborating (passing) perspectives reside in at least 2 distinct Regional Internet Registries (RIRs) per the "Phased Implementation Timeline" in BRs section 3.2.2.9 ("Effective March 15, 2026"). - Including an MPIC summary consisting of: passing perspectives, failing perspectives, passing RIRs, and a quorum met for issuance (e.g., 2/3 or 3/3) in each validation audit log event, per BRs Section 5.4.1, Requirement 2.8. When the new SeparateDCVAndCAAChecks feature flag is enabled on the RA, calls to VA.IsCAAValid (during finalization) and VA.PerformValidation (during challenge) are replaced with calls to VA.DoCAA and a sequence of VA.DoDCV followed by VA.DoCAA, respectively. Fixes #7612 Fixes #7614 Fixes #7615 Fixes #7616

2024-12-05

WIP

2024-11-27

VA: Make performRemoteValidation more generic (#7847) - Make performRemoteValidation a more generic function that returns a new remoteResult interface - Modify the return value of IsCAAValid and PerformValidation to satisfy the remoteResult interface - Include compile time checks and tests that pass an arbitrary operation

2024-11-25

WIP

2024-11-20

Merge remote-tracking branch 'origin/main' into mpic-part-two

2024-11-19

ratelimit: Remove legacy registrations per IP implementation (#7760) Part of #7671

Merge remote-tracking branch 'origin/main' into mpic-part-two

2024-11-14

expectedKeyAuthorization

Comment grammar and removing a renaming

Addressing comments

2024-11-13

VA: Add a method for performing MPIC compliant CAA checks

2024-11-08

VA: Add a method for performing MPIC compliant challenge validation

2024-11-06

Introduce separate UpdateRegistrationContact & UpdateRegistrationKey methods in RA & SA (#7735) Introduce separate UpdateRegistrationContact & UpdateRegistrationKey methods in RA & SA Clear contact field during DeactivateRegistration Part of #7716 Part of #5554

2024-10-31

WIP

2024-10-10

VA/RVA: Add metadata necessary for the MPIC ballot (#7732) - 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

2024-08-30

Lay the groundwork for supporting IP identifiers (#7692) Clean up how we handle identifiers throughout the Boulder codebase by - moving the Identifier protobuf message definition from sa.proto to core.proto; - adding support for IP identifier to the "identifier" package; - renaming the "identifier" package's exported names to be clearer; and - ensuring we use the identifier package's helper functions everywhere we can. This will make future work to actually respect identifier types (such as in Authorization and Order protobuf messages) simpler and easier to review. Part of https://github.com/letsencrypt/boulder/issues/7311

2024-08-15

Remove deprecated sapb.Authorizations.Authz "map" (#7658) This field was deprecated in https://github.com/letsencrypt/boulder/pull/7646 and the last uses of it were removed in https://github.com/letsencrypt/boulder/pull/7650.

Remove deprecated sapb.NewAuthzRequest fields (#7651) Remove the id, identifierValue, status, and challenges fields from sapb.NewAuthzRequest. These fields were left behind from the previous corepb.Authorization request type, and are now being ignored by the SA. Since the RA is no longer constructing full challenge objects to include in the request, remove pa.ChallengesFor and replace it with the much simpler pa.ChallengeTypesFor. Part of https://github.com/letsencrypt/boulder/issues/5913

2024-08-12

Use consistent naming for dnsName gRPC fields (#7654) Find all gRPC fields which represent DNS Names -- sometimes called "identifier", "hostname", "domain", "identifierValue", or other things -- and unify their naming. This naming makes it very clear that these values are strings which may be included in the SAN extension of a certificate with type dnsName. As we move towards issuing IP Address certificates, all of these fields will need to be replaced by fields which carry both an identifier type and value, not just a single name. This unified naming makes it very clear which messages and methods need to be updated to support non-dnsName identifiers. Part of https://github.com/letsencrypt/boulder/issues/7647

Remove challenge.ProvidedKeyAuthorization (#7655) This field was deprecated in https://github.com/letsencrypt/boulder/pull/7515, and has been fully replaced by vapb.PerformValidationRequest.ExpectedKeyAuthorization. Fixes https://github.com/letsencrypt/boulder/issues/7514

RA: Add GetAuthorization method to filter disabled challenges (#7652) Add a new "GetAuthorization" method to the RA. This method is very similar to the SA's existing "GetAuthorization2" method, except that it also uses the RA's built-in Policy Authority to filter out any challenges which are currently disabled. In a follow-up change, the WFE will be updated to use this method when retrieving authorizations and challenges for display, so that we can ensure disabled challenges are not presented to ACME clients. Part of https://github.com/letsencrypt/boulder/issues/5913

2024-08-08

Simplify GetValidOrderAuthorizations2 (#7646) Simplify SA.GetValidOrderAuthorizations2 so that it no longer conditions the query on the status, expiry, or registration ID of the authorization rows. This gives the query much better performance, because it no longer tries to use an overly-large index, and fall back to large row-scans when the query planner decides the index is too large. While we're here, also improve the return type of GetValidOrderAuthorizations2, so that instead of returning a map of names to authorizations, it simply returns a list of authzs. This both reduces the size of the gRPC message (once the old map is fully removed), and improves its correctness because we cannot count on names to be unique across multiple identifier types. Finally, improve the RA code which calls SA.GetValidOrderAuthorizations2 to handle this improved return type, to make fewer assumptions about identifier types, and to separate static authorization-checking from CAA rechecking. Fixes https://github.com/letsencrypt/boulder/issues/7645

Improve how we create new authorizations (#7643) Within the NewOrderAndAuthzsRequest, replace the corepb.Authorization field with a new sapb.NewAuthzRequest message. This message has all of the same field types and numbers, and the RA still populates all of these fields when constructing a request, for backwards compatibility. But it also has new fields (an Identifier carrying both type and value, a list of challenge types, and a challenge token) which the RA preferentially consumes if present. This causes the content of our NewOrderAndAuthzsRequest to more closely match the content that will be created at the database layer. Although this may seem like a step backwards in terms of abstraction, it is also a step forwards in terms of both efficiency (not having to transmit multiple nearly-identical challenge objects) and correctness (being guaranteed that the token is actually identical across all challenges). After this change is deployed, it will be followed by a change which removes the old fields from the NewAuthzRequest message, to realize the efficiency gains. Part of https://github.com/letsencrypt/boulder/issues/5913

2024-08-07

Delete sa.GetPendingAuthorization2 (#7648) This method's last caller was removed in https://github.com/letsencrypt/boulder/pull/5862, when the ACMEv1 NewAuthorization code path was deleted. It has been dead code ever since.

2024-07-25

RA: pass through unpause requests to SA (#7630) Have the RA's UnpauseAccount gRPC method forward the requested account ID to the SA's corresponding method, and in turn forward the SA's count of unpaused identifiers back to the caller in the response. Changing the response message from emptypb.Empty to a new rapb.UnpauseAccountResponse is safe, because message names are not transmitted on the wire, only message field numbers. While we're here, drastically simplify the wfe_test and sfe_test Mock RAs, so they don't have to implement methods that aren't actually used by the tests. Fixes https://github.com/letsencrypt/boulder/issues/7536

Rename 'now' to 'validUntil' in GetAuthz requests (#7631) The name "now" was always misleading, because we never set the value to be the actual current time, we always set it to be some time in the future to avoid returning authzs which expire in the very near future. Changing the name to "validUntil" matches the current naming in GetPendingAuthorizationRequest.

2024-07-10

sa: Avoid database timeouts in UnpauseAccount (#7572) SA method UnpauseAccount uses up to 5 `UPDATE` query iterations, each with a `LIMIT` of 10000, to unpause up to 50000 identifiers and returns a count of identifiers unpaused. Part of #7475

2024-06-27

ratelimits: Exempt renewals from NewOrdersPerAccount and CertificatesPerDomain (#7513) - Rename `NewOrderRequest` field `LimitsExempt` to `IsARIRenewal` - Introduce a new `NewOrderRequest` field, `IsRenewal` - Introduce a new (temporary) feature flag, `CheckRenewalExemptionAtWFE` WFE: - Perform renewal detection in the WFE when `CheckRenewalExemptionAtWFE` is set - Skip (key-value) `NewOrdersPerAccount` and `CertificatesPerDomain` limit checks when renewal detection indicates the the order is a renewal. RA: - Leave renewal detection in the RA intact - Skip renewal detection and (legacy) `NewOrdersPerAccount` and `CertificatesPerDomain` limit checks when `CheckRenewalExemptionAtWFE` is set and the `NewOrderRequest` indicates that the order is a renewal. Fixes #7508 Part of #5545

2024-06-20

RA: Add UnpauseAccountRequest protobuf message and service (#7537) Add the `ra.UnpauseAccount` which takes an `rapb.UnpauseAccountRequest` input parameter. The method is just a stub to allow downstream SFE development to continue. There is relevant ongoing work in the SA which will eventually reside in this stub method.

2024-06-17

SA: Implement schema and methods for (account, hostname) pausing (#7490) Add the storage implementation for our new (account, hostname) pair pausing feature. - Add schema and model for for the new paused table - Add SA service methods for interacting with the paused table Part of #7406 Part of #7475

2024-06-04

Deprecate Challenge.ProvidedKeyAuthorization (#7515) The core.Challenge.ProvidedKeyAuthorization field is problematic, both because it is poorly named (which is admittedly easily fixable) and because it is a field which we never expose to the client yet it is held on a core type. Deprecate this field, and replace it with a new vapb.PerformValidationRequest.ExpectedKeyAuthorization field. Within the VA, this also simplifies the primary logic methods to just take the expected key authorization, rather than taking a whole (largely unnecessary) challenge object. This has large but wholly mechanical knock-on effects on the unit tests. While we're here, improve the documentation on core.Challenge itself, and remove Challenge.URI, which was deprecated long ago and is wholly unused. Part of https://github.com/letsencrypt/boulder/issues/7514

2024-05-29

update otel dependencies to v1.27.0 and v0.52.0 (#7496) Directly update: - go.opentelemetry.io/otel/* from v1.26.0 to v1.27.0 - go.opentelemetry.io/contrib/* from v0.51.0 to v0.52.0 Indirectly update: - google.golang.org/protobuf from v1.33.0 to v1.34.0 This update breaks some of our existing otel grpc interceptors, but in return allows us to use the newer grpc StatsHandler mechanism, while still filtering out health-check requests. Fixes https://github.com/letsencrypt/boulder/issues/7235

2024-04-23

RA: Audit log and track cert profile names and hashes (#7433) * Adds `CertProfileName` to the CAs `capb.IssuePrecertificateResponse` so the RA can receive the CAs configured default profile name for audit logging/metrics. This is useful for when the RA sends an empty string as the profile name to the CA, but we want to know exactly what the profile name chosen by the CA was, rather than just relying on comparing hashes between CA and RA audit logs. * Adds the profile name and hash to RA audit logs emitted after a successful issuance. * Adds new labels to the existing `new_certificates` metric exported by the RA. ``` # HELP new_certificates A counter of new certificates including the certificate profile name and hexadecimal certificate profile hash # TYPE new_certificates counter new_certificates{profileHash="de4c8c8866ed46b1d4af0d79e6b7ecf2d1ea625e26adcbbd3979ececd8fbd05a",profileName="defaultBoulderCertificateProfile"} 2 ``` Fixes https://github.com/letsencrypt/boulder/issues/7421

2024-04-18

SA: Remove unused PreviousCertificateExists method (#7439) This method has had no callers since the removal of ACMEv1.

2024-04-04

Remove IssueCertificateRequest.IssuerNameID (#7409) This field was introduced in https://github.com/letsencrypt/boulder/pull/5222 to allow the old v1 WFEs to continue to tightly control which issuers were used, rather than letting the CA dynamically pick an issuer based on the to-be-issued certificate's public key. The plumbing between the v1 WFEs and the RA was removed in https://github.com/letsencrypt/boulder/pull/5900, and this has been dead code ever since. Part of https://github.com/letsencrypt/boulder/issues/7291

2024-03-19

build(deps): bump google.golang.org/protobuf from 1.32.0 to 1.33.0 (#7384) Updates google.golang.org/protobuf from 1.32.0 to 1.33.0 Also updates github.com/golang/protobuf from 1.5.3 to 1.5.4

2024-03-14

Add certificateProfileName to RA, SA, and Core order protos (#7381) This adds the profile name to the proto messages necessary to propagate it from the WFE to the SA, and from the SA to the CA. This change is safe to land prior to any logic being added, and unblocks profile-handling logic changes to the WFE, RA, SA, and CA. Part of https://github.com/letsencrypt/boulder/issues/7309

2024-03-11

admin: use SA to get serials by account and by SPKI hash (#7369) Add two new methods to the SA, GetSerialsByKey and GetSerialsByAccount, which use the same query as the admin tool has previously used to get serials matching a given SPKI hash or a given registration ID. These two new gRPC methods read the database row-by-row and produce streams of results to keep SA memory usage low. Use these methods in the admin tool so it no longer needs a direct database connection for these actions. Part of https://github.com/letsencrypt/boulder/issues/7350

2024-03-05

CA: gRPC plumbing for multiple certificate profiles (#7331) Adds a new `certProfileName` message to the `CA.IssueCertificateRequest`. This field contains a human-readable "name" set by the [WFE2](https://github.com/letsencrypt/boulder/issues/7332), and in turn the RA. At the time of precertificate issuance, the receiving CA will determine if it is capable of fulfilling the `ra.CA.IssuePrecertificate` request for the given `certProfileName`. If the name is found in the CA's map, the CA will return a `capb.IssuePrecertificateResponse` message with a populated `certProfileHash` field back to the RA. When that RA calls `ra.CA.IssueCertificateForPrecertificate`, it will send that same `certProfileHash` message to a CA which must ensure it contains a certificate profile matching the provided hash. If the hash in found in the CA's map a final certificate issuance attempt will proceed. This is done to prevent certificate profile changes in the duration between requests from causing a mismatch between precerticate and final certificate. Part of https://github.com/letsencrypt/boulder/issues/7309 Part of https://github.com/letsencrypt/boulder/issues/6966

2024-02-12

RA/ARI: Add method for tracking certificate replacement (#7293) - Add new `replaces` field to RA.NewOrder requests - Pass new `replaces` field to `SA.NewOrderAndAuthzs` - Add new `limitsExempt` field to RA.NewOrder requests - Ensure the RA follows this exemption for all NewOrder rate limits

2024-02-08

SA/ARI: Add method of tracking certificate replacement (#7284) Part of #6732 Part of #7038

2024-02-05

va: Audit log which DNS resolver performs a lookup (#7271) Adds the chosen DNS resolver to the VAs `ValidationRecord` object so that for each challenge type during a validation, boulder can audit log the resolver(s) chosen to fulfill the request.. Fixes https://github.com/letsencrypt/boulder/issues/7140

2024-01-31

Merge branch 'main' into ari-new-order-replacement

2024-01-29

RA: improve AdministrativelyRevokeCertificate (#7275) The RA.AdministrativelyRevokeCertificate method has two primary modes of operation: if a certificate DER blob is provided, it parses and extracts information from that blob, and revokes the cert; if no DER is provided, it assumes the cert is malformed, and revokes it (but doesn't do an OCSP cache purge) based on the serial alone. However, this scheme has slightly confusing semantics in the RA and requires that the admin tooling look up the certificates to provide them to the RA. Instead, add a new "malformed" field to the RA's AdministrativelyRevokeCertificateRequest, and deprecate the "cert" field of that same request. When the malformed boolean is false, the RA will look up and parse the certificate itself. When the malformed field is true, it will revoke the cert based on serial alone. Note that the main logic of AdministrativelyRevokeCertificate -- namely revoking, potentially re-revoking, doing an akamai cache purge, etc -- is not changed by this PR. The only thing that changes here is how the RA gets access to the to-be-revoked certificate's information. Part of https://github.com/letsencrypt/boulder/issues/7135

2024-01-26

replacementCertificates

2024-01-25

WIP

2024-01-23

SA: Add GetLintPrecertificate gRPC method (#7274) Add a new "GetLintPrecertificate" method to the SA's gRPC service. This acts identically to the existing "GetCertificate", but returns the linting precertificate created just prior to the actual precertificate instead. This is useful for revocation, where we need to be able to act on a serial even if the corresponding (pre)certificate was never issued or never saved to the database. Part of https://github.com/letsencrypt/boulder/issues/7135

2024-01-22

RA: improve AdministrativelyRevokeCertificate

SA: Add GetLintPrecertificate gRPC method

2023-12-01

Merge branch 'main' into rva-recheck-caa

2023-11-30

Publisher: clean up deprecated Request.Precert field (#7165) Now that the RA is using the pubpb.Request.Kind field, we can delete and clean up all references to the older Precert field. Part of https://github.com/letsencrypt/boulder/issues/7161

2023-11-28

Finish migration from int64 durations to durationpb (#7147) This is a cleanup PR finishing the migration from int64 durations to protobuf `*durationpb.Duration` by removing all usage of the old int64 fields. In the previous PR https://github.com/letsencrypt/boulder/pull/7146 all fields were switched to read from the protobuf durationpb fields. Fixes https://github.com/letsencrypt/boulder/issues/7097

2023-11-27

Finish migration from int64 timestamps to timestamppb (#7142) This is a cleanup PR finishing the migration from int64 timestamps to protobuf `*timestamppb.Timestamps` by removing all usage of the old int64 fields. In the previous PR https://github.com/letsencrypt/boulder/pull/7121 all fields were switched to read from the protobuf timestamppb fields. Adds a new case to `core.IsAnyNilOrZero` to check various properties of a `*timestamppb.Timestamp` reducing the visual complexity for receivers. Fixes https://github.com/letsencrypt/boulder/issues/7060

Publisher: expose submission type in metric labels (#7163) Give the publisher a more nuanced view of the three kinds of CT submissions we do: "sct" (submitting a precert to get SCTs), "info" (submitting a precert but not caring about the result), and "final" (submitting a final cert and not caring about the result). Expose these three kinds in the ct_errors_count and ct_submission_time_seconds metrics, so that they can be separately grouped and alerted on. This is an improvement over the current status-quo, which only distinguishes between "precert" and "final" submissions, without being able to distinguish between SCT-retrieving and purely-informational submissions of precerts. This functionality will not be fully operational until the RA begins informing the publisher of what kind of submission this is. Part of https://github.com/letsencrypt/boulder/issues/7161