signed certs have empty AKI?
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 45/100
Research direction
Reproduce the sequence using csr.json, cfssl genkey, cfssl sign, and cfssl certinfo with cfssl 1.6.5, then inspect server.pem for its authority key identifier. Compare the generated server certificate with the self-signed root and determine whether the empty AKI is expected; done means the behavior and its relationship to the reported TLS verification failure are established.
Written by the indexing model from the issue text.
Description
i run the following sequence of commands to generate a self-signed root ca, and sign a server cert with it
cfssl genkey -initca csr.json | cfssljson -bare root
cfssl genkey csr.json | cfssljson -bare server
cfssl sign -ca root.pem -ca-key root-key.pem server.csr | cfssljson -bare server
csr.json contents:
{
"hosts": ["localhost", "127.0.0.1"],
"key": {
"algo": "ecdsa",
"size": 256
},
"CN": "localhost",
"names": []
}
i see no errors in the process
then i run
cfssl certinfo -cert server.pem
and see the following line
"authority_key_id": ""
i have an app with gRPC using TLS that fails (most likely because of the issue) with the following error
transport: authentication handshake failed: tls: failed to verify certificate: x509: certificate signed by unknown authority
my cfssl
cfssl version
outputs
Version: 1.6.5
Runtime: go1.23.0
i see in README that AKI is not set for self-signed certs which is perfectly reasonable, but server here is not self-signed.
- Dominant language
- Go
- Stars
- 9.5k
- Forks
- 1.2k
- Avg merge
- 5d 1h
- Merged PRs (30d)
- 5
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from cloudflare/cfssl
-
gencrl: serial numbers that fail to parse are added to the CRL as 0 or a partial valuePossibly taken @sebxt claimed this 3 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
cloudflare/cfssl#1460 ·
Maintainers usually reply within 2 days
-
crl_override (and extensions) in /api/v1/sign request body are silently ignored by the HTTP APIPossibly taken @Hashim1999164 claimed this 72 days ago. Open
Difficulty 2/5 Half a day Newbie friendliness 78/100
cloudflare/cfssl#1439 ·
Maintainers usually reply within 2 days
-
gencrl silently revokes the wrong serial number when a line is not plain decimalPossibly taken @RaphaelFakhri claimed this 4 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 30/100
cloudflare/cfssl#1458 ·
Maintainers usually reply within 2 days
-
config: LoadConfig panics when not_after is before not_beforePossibly taken @sebxt claimed this 5 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 25/100
cloudflare/cfssl#1456 ·
Maintainers usually reply within 2 days
-
Difficulty 3/5 1-2 days Newbie friendliness 48/100
cloudflare/cfssl#1446 ·
Maintainers usually reply within 2 days
All issues in cloudflare/cfssl
Similar issues
-
compress: block buffers get re-zeroed on every call, and the zeroing is immediately overwrittenOpen
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
ClickHouse/ch-go#1218 ·
Maintainers usually reply within 13 days
-
automation models
Difficulty 1/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
podman-container-tools/podman#30031 ·
Maintainers usually reply within 1 day