...

Package notmain

import "github.com/letsencrypt/boulder/cmd/boulder-ra"
Overview
Index

Overview ▾

Index ▾

Package files

main.go

type Config

type Config struct {
    RA struct {
        cmd.ServiceConfig
        cmd.HostnamePolicyConfig

        RateLimitPoliciesFilename string `validate:"required"`

        MaxContactsPerRegistration int

        SAService           *cmd.GRPCClientConfig
        VAService           *cmd.GRPCClientConfig
        CAService           *cmd.GRPCClientConfig
        OCSPService         *cmd.GRPCClientConfig
        PublisherService    *cmd.GRPCClientConfig
        AkamaiPurgerService *cmd.GRPCClientConfig

        MaxNames int `validate:"required,min=1"`

        // AuthorizationLifetimeDays defines how long authorizations will be
        // considered valid for. Given a value of 300 days when used with a 90-day
        // cert lifetime, this allows creation of certs that will cover a whole
        // year, plus a grace period of a month.
        AuthorizationLifetimeDays int `validate:"required,min=1,max=397"`

        // PendingAuthorizationLifetimeDays defines how long authorizations may be in
        // the pending state. If you can't respond to a challenge this quickly, then
        // you need to request a new challenge.
        PendingAuthorizationLifetimeDays int `validate:"required,min=1,max=29"`

        // GoodKey is an embedded config stanza for the goodkey library.
        GoodKey goodkey.Config

        // OrderLifetime is how far in the future an Order's expiration date should
        // be set when it is first created.
        OrderLifetime config.Duration

        // FinalizeTimeout is how long the RA is willing to wait for the Order
        // finalization process to take. This config parameter only has an effect
        // if the AsyncFinalization feature flag is enabled. Any systems which
        // manage the shutdown of an RA must be willing to wait at least this long
        // after sending the shutdown signal, to allow background goroutines to
        // complete.
        FinalizeTimeout config.Duration `validate:"-"`

        // CTLogs contains groupings of CT logs organized by what organization
        // operates them. When we submit precerts to logs in order to get SCTs, we
        // will submit the cert to one randomly-chosen log from each group, and use
        // the SCTs from the first two groups which reply. This allows us to comply
        // with various CT policies that require (for certs with short lifetimes
        // like ours) two SCTs from logs run by different operators. It also holds
        // a `Stagger` value controlling how long we wait for one operator group
        // to respond before trying a different one.
        CTLogs ctconfig.CTConfig
        // InformationalCTLogs are a set of CT logs we will always submit to
        // but won't ever use the SCTs from. This may be because we want to
        // test them or because they are not yet approved by a browser/root
        // program but we still want our certs to end up there.
        InformationalCTLogs []ctconfig.LogDescription

        // IssuerCerts are paths to all intermediate certificates which may have
        // been used to issue certificates in the last 90 days. These are used to
        // generate OCSP URLs to purge during revocation.
        IssuerCerts []string `validate:"min=1,dive,required"`

        Features map[string]bool
    }

    PA cmd.PAConfig

    Syslog        cmd.SyslogConfig
    OpenTelemetry cmd.OpenTelemetryConfig
}