crypto: certificate & TLS hardening

[Jakob3xD]

Summary

Certificate/TLS hardening findings in internal/crypto/crypto.go and internal/datastore/datastore.go. None is remotely exploitable on its own; these are least-privilege / robustness improvements.

Findings

1. Client-auth certificate gets overly broad Extended Key Usages (Medium)

internal/crypto/crypto.go:269-273

NewCertificateTemplate (used for etcd client authentication, datastore_certificate.go:143) sets ExtKeyUsage to ClientAuth, ServerAuth and CodeSigning. For a pure client-auth certificate, ServerAuth/CodeSigning are unnecessary. The subject organization is also system:masters (line 264), i.e. a highly privileged etcd identity — if the key leaks it is additionally abusable as a server cert and for code signing.

Fix: restrict EKU to x509.ExtKeyUsageClientAuth.

2. Certificate serial number from math/rand; static SubjectKeyId (Low)

internal/crypto/crypto.go:16,261,268

SerialNumber: big.NewInt(mathrand.Int63()),
SubjectKeyId: []byte{1, 2, 3, 4, 6},

math/rand is non-cryptographic and unseeded (deterministic per process start); SubjectKeyId is hardcoded for all certificates. The rest of the package correctly uses crypto/rand. Low risk (internal auth CA, signing itself uses crypto/rand), but violates RFC 5280's unique-serial recommendation.

Fix: generate the serial via crypto/rand.Int(rand.Reader, limit); derive SubjectKeyId from the SHA-1 of the public key.

3. TLS client config without explicit MinVersion (Low)

internal/datastore/datastore.go:51-53

The constructed tls.Config sets only RootCAs/Certificates, no MinVersion. (No InsecureSkipVerify anywhere — good.) Impact is minimal since Go's client default floor is already TLS 1.2; purely defensive against future default changes.

Fix: set MinVersion: tls.VersionTLS12 explicitly.

---

🤖 Reported as part of a Claude Code audit.