certificate-transparency-go

Auditing for TLS certificates (Go code)

1,021

271

1,021

View on GitHub

Top Related Projects

trillian

3,644

A transparent, highly scalable and cryptographically verifiable data store.

boulder

5,512

An ACME-based certificate authority, written in Go.

mkcert

54,084

A simple zero-config tool to make locally trusted development certificates with any names you'd like.

Quick Overview

Certificate Transparency Go (CT Go) is an open-source implementation of Certificate Transparency (CT) in Go. It provides tools and libraries for working with CT logs, including log operators, monitors, and auditors. This project is part of Google's efforts to make the web more secure by improving the way SSL/TLS certificates are issued and monitored.

Pros

Robust implementation of Certificate Transparency protocols
Written in Go, offering good performance and concurrency support
Actively maintained by Google and the open-source community
Provides both client and server-side components for CT operations

Cons

Requires understanding of Certificate Transparency concepts
Documentation could be more comprehensive for newcomers
Limited cross-platform GUI tools (primarily command-line focused)
May require additional setup for integration with existing certificate management systems

Code Examples

Creating a CT client:

import "github.com/google/certificate-transparency-go/client"

c, err := client.New("https://ct.googleapis.com/logs/argon2022/", nil, nil)
if err != nil {
    // Handle error
}

Submitting a certificate to a CT log:

import "github.com/google/certificate-transparency-go/client"

sct, err := c.AddChain(ctx, chain)
if err != nil {
    // Handle error
}
fmt.Printf("SCT: %v\n", sct)

Verifying a Signed Certificate Timestamp (SCT):

import "github.com/google/certificate-transparency-go/tls"

sct, err := tls.ParseSCT(sctData)
if err != nil {
    // Handle error
}
err = verifier.VerifySCT(leaf, sct)
if err != nil {
    // Handle verification error
}

Getting Started

To use Certificate Transparency Go in your project:

Install Go (version 1.11 or later)
Run: go get github.com/google/certificate-transparency-go
Import the required packages in your Go code:

import (
    "github.com/google/certificate-transparency-go/client"
    "github.com/google/certificate-transparency-go/jsonclient"
    "github.com/google/certificate-transparency-go/tls"
)

Start using the CT Go functions in your application as shown in the code examples above.

Competitor Comparisons

trillian

3,644

A transparent, highly scalable and cryptographically verifiable data store.

Pros of Trillian

More versatile: Trillian is a general-purpose verifiable data store, while certificate-transparency-go is specific to Certificate Transparency
Better scalability: Designed to handle large-scale data storage and verification
Active development: More frequent updates and contributions

Cons of Trillian

Steeper learning curve: Requires more setup and configuration due to its general-purpose nature
Potentially overkill: May be unnecessarily complex for projects only needing Certificate Transparency functionality

Code Comparison

certificate-transparency-go:

logClient, err := client.New(logURL, nil, opts)
if err != nil {
    return nil, fmt.Errorf("failed to create log client: %v", err)
}

Trillian:

adminClient := trillian.NewTrillianAdminClient(conn)
treeClient := trillian.NewTrillianLogClient(conn)
tree, err := adminClient.CreateTree(ctx, &trillian.CreateTreeRequest{
    Tree: &trillian.Tree{TreeState: trillian.TreeState_ACTIVE},
})

The code snippets demonstrate that certificate-transparency-go is more focused on creating a log client for Certificate Transparency, while Trillian provides a more general-purpose API for creating and managing verifiable data structures.

boulder

5,512

An ACME-based certificate authority, written in Go.

Pros of Boulder

Comprehensive ACME server implementation for issuing SSL/TLS certificates
Extensive documentation and community support
Designed for high-volume certificate issuance

Cons of Boulder

More complex setup and configuration
Focused specifically on ACME protocol, less versatile for other certificate-related tasks
Steeper learning curve for newcomers

Code Comparison

Boulder (Go):

func (ra *RegistrationAuthorityImpl) NewAuthorization(ctx context.Context, request core.Authorization, regID int64) (core.Authorization, error) {
    identifier := request.Identifier
    if identifier.Type != core.IdentifierDNS {
        return core.Authorization{}, berrors.MalformedError("invalid identifier type")
    }
    // ... (additional code)
}

Certificate-Transparency-Go:

func (c *LogClient) AddChain(ctx context.Context, chain []ct.ASN1Cert) (*ct.SignedCertificateTimestamp, error) {
    req := addChainRequest{Chain: chain}
    var resp addChainResponse
    httpRsp, body, err := c.postAndParse(ctx, c.uri+AddChainPath, &req, &resp)
    if err != nil {
        return nil, err
    }
    // ... (additional code)
}

Boulder is tailored for ACME certificate issuance, while Certificate-Transparency-Go focuses on certificate transparency log operations. Boulder's code deals with authorization and registration, whereas Certificate-Transparency-Go handles adding certificate chains to transparency logs.

mkcert

54,084

A simple zero-config tool to make locally trusted development certificates with any names you'd like.

Pros of mkcert

Simpler and more user-friendly for local development purposes
Focuses on creating locally-trusted development certificates
Lightweight and easy to install

Cons of mkcert

Limited scope compared to certificate-transparency-go's broader functionality
Not suitable for production-level certificate management
Lacks advanced features for certificate transparency and monitoring

Code Comparison

mkcert:

func (m *mkcert) makeCert(hosts []string) (cert []byte, key []byte, err error) {
    priv, err := m.generateKey(hosts[0])
    if err != nil {
        return
    }
    pub := priv.(crypto.Signer).Public()
    // ... (additional code)
}

certificate-transparency-go:

func (c *LogClient) AddChain(ctx context.Context, chain []ct.ASN1Cert) (*ct.SignedCertificateTimestamp, error) {
    req := addChainRequest{Chain: chain}
    var resp addChainResponse
    httpRsp, body, err := c.postAndParse(ctx, ct.AddChainPath, &req, &resp)
    if err != nil {
        return nil, err
    }
    // ... (additional code)
}

The code snippets highlight the different focus areas of the two projects. mkcert is centered around creating certificates for local development, while certificate-transparency-go deals with more complex certificate transparency operations.

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Certificate Transparency: Go Code

This repository holds Go code related to Certificate Transparency (CT). The repository requires Go version 1.23.

Repository Structure
Trillian CT Personality
Working on the Code
- Running Codebase Checks
- Rebuilding Generated Code

Support

Slack: https://transparency-dev.slack.com/ (invitation)

Repository Structure

The main parts of the repository are:

Encoding libraries:
- asn1/ and x509/ are forks of the upstream Go encoding/asn1 and crypto/x509 libraries. We maintain separate forks of these packages because CT is intended to act as an observatory of certificates across the ecosystem; as such, we need to be able to process somewhat-malformed certificates that the stricter upstream code would (correctly) reject. Our x509 fork also includes code for working with the pre-certificates defined in RFC 6962.
- tls holds a library for processing TLS-encoded data as described in RFC 5246.
- x509util/ provides additional utilities for dealing with x509.Certificates.
CT client libraries:
- The top-level ct package (in .) holds types and utilities for working with CT data structures defined in RFC 6962.
- client/ and jsonclient/ hold libraries that allow access to CT Logs via HTTP entrypoints described in section 4 of RFC 6962.
- dnsclient/ has a library that allows access to CT Logs over DNS.
- scanner/ holds a library for scanning the entire contents of an existing CT Log.
CT Personality for Trillian:
- trillian/ holds code that allows a Certificate Transparency Log to be run using a Trillian Log as its back-end -- see below.
Command line tools:
- ./client/ctclient allows interaction with a CT Log.
- ./ctutil/sctcheck allows SCTs (signed certificate timestamps) from a CT Log to be verified.
- ./scanner/scanlog allows an existing CT Log to be scanned for certificates of interest; please be polite when running this tool against a Log.
- ./x509util/certcheck allows display and verification of certificates
- ./x509util/crlcheck allows display and verification of certificate revocation lists (CRLs).
Other libraries related to CT:
- ctutil/ holds utility functions for validating and verifying CT data structures.
- loglist3/ has a library for reading v3 JSON lists of CT Logs.

Trillian CT Personality

The trillian/ subdirectory holds code and scripts for running a CT Log based on the Trillian general transparency Log, and is documented separately.

Working on the Code

Developers who want to make changes to the codebase need some additional dependencies and tools, described in the following sections.

Running Codebase Checks

The scripts/presubmit.sh script runs various tools and tests over the codebase; please ensure this script passes before sending pull requests for review.

# Install golangci-lint
go install github.com/golangci/golangci-lint/v2/cmd/golangci-lint@v2.1.6

# Run code generation, build, test and linters
./scripts/presubmit.sh

# Run build, test and linters but skip code generation
./scripts/presubmit.sh  --no-generate

# Or just run the linters alone:
golangci-lint run

Rebuilding Generated Code

Some of the CT Go code is autogenerated from other files:

Protocol buffer message definitions are converted to .pb.go implementations.
A mock implementation of the Trillian gRPC API (in trillian/mockclient) is created with GoMock.

Re-generating mock or protobuffer files is only needed if you're changing the original files; if you do, you'll need to install the prerequisites:

tools written in go can be installed with a single run of go install (courtesy of tools.go and go.mod).
protoc tool: you'll need version 3.20.1 installed, and PATH updated to include its bin/ directory.

With tools installed, run the following:

go generate -x ./...  # hunts for //go:generate comments and runs them

Top Related Projects

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot