Smallstep CA might be interesting for you too. It’s open source. https://smallstep.com/docs/step-ca/getting-started/
We use Smallstep at work and it's a pleasure to work with! Definitely recommend checking it out.
Setting up a trusted, self-signed SSL/TLS certificate authority in Linux
31–39 of 39 posts
Re: Setting up a trusted, self-signed SSL/TLS certificate authority in Linux
#32See also easy-rsa https://github.com/OpenVPN/easy-rsa
Re: Setting up a trusted, self-signed SSL/TLS certificate authority in Linux
#33[deleted]
Re: Setting up a trusted, self-signed SSL/TLS certificate authority in Linux
#34I really wish that we would have the option to get rid of CAs and just use DNSSEC as the root of the chain of trust.
Is it coming? I notice that OpenSSL now has support for raw public keys. The spec (RFC 7250, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)") suggests DANE/DNSSEC as a mechanism to bind identities to public keys (section 6). https://datatracker.ietf.org/doc/html/rfc7250 Will this really be simpler?
Simpler and faster I hope.
Re: Setting up a trusted, self-signed SSL/TLS certificate authority in Linux
#35I really wish that we would have the option to get rid of CAs and just use DNSSEC as the root of the chain of trust.
Is it coming? I notice that OpenSSL now has support for raw public keys. The spec (RFC 7250, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)") suggests DANE/DNSSEC as a mechanism to bind identities to public keys (section 6). https://datatracker.ietf.org/doc/html/rfc7250 Will this really be simpler?
It is not coming. Browsers are unlikely to support DANE (Chrome briefly did, and then pulled support, IIRC).
Re: Setting up a trusted, self-signed SSL/TLS certificate authority in Linux
#36Earlier quoted context omitted.
Is it coming? I notice that OpenSSL now has support for raw public keys. The spec (RFC 7250, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)") suggests DANE/DNSSEC as a mechanism to bind identities to public keys (section 6). https://datatracker.ietf.org/doc/html/rfc7250 Will this really be simpler?
Simpler and faster I hope.
In fact, the slowness and complexity of DANE is a big part of why it got pulled.
Re: Setting up a trusted, self-signed SSL/TLS certificate authority in Linux
#37Earlier quoted context omitted.
https://github.com/caddyserver/caddy/issues/5759 : > When generating a CA cert via caddy and putting that in the trust store, those private keys can also forge certificates for any other domain. RFC5280 ( 2008 ) "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" > Section 4.2.1.10 Name Constraints: https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.... : > Th…
If this is now finally supported that's great. The issue was that for it to be useful it has to be marked critical / fail-closed, because a CA with ignored name constraint == an unrestricted CA. But if you make it critical, then clients who don't understand it will just fail. You can see how this doesn't help adoption.
It says "Proposed Standard" on the RFC; maybe that's why it's not widely implemented if that's the case?
https://bettertls.com/ has Name Constraints implementation validation tests, but "Archived Results" doesn't seem to have recent versions of SSL clients listed?
nameConstraints=critical,
> Registrants publish a "CAA" Domain Name System (DNS) resource record which compliant certificate authorities check for before issuing digital certificates.
And hopefully they require DNSSEC signatures and DoH/DoT/DoQ when querying for CAA records.
Re: Setting up a trusted, self-signed SSL/TLS certificate authority in Linux
#38Earlier quoted context omitted.
If this is now finally supported that's great. The issue was that for it to be useful it has to be marked critical / fail-closed, because a CA with ignored name constraint == an unrestricted CA. But if you make it critical, then clients who don't understand it will just fail. You can see how this doesn't help adoption.
It says "Proposed Standard" on the RFC; maybe that's why it's not widely implemented if that's the case? https://bettertls.com/ has Name Constraints implementation validation tests, but "Archived Results" doesn't seem to have recent versions of SSL clients listed? nameConstraints=critical, DNS Certification Authority Authorization: https://en.wikipedia.org/wiki/DNS_Certification_Authority_Au... : > Registrants publis…
CAA does not require DNSSEC or DOH.
Re: Setting up a trusted, self-signed SSL/TLS certificate authority in Linux
#39Earlier quoted context omitted.
If this is now finally supported that's great. The issue was that for it to be useful it has to be marked critical / fail-closed, because a CA with ignored name constraint == an unrestricted CA. But if you make it critical, then clients who don't understand it will just fail. You can see how this doesn't help adoption.
It says "Proposed Standard" on the RFC; maybe that's why it's not widely implemented if that's the case? https://bettertls.com/ has Name Constraints implementation validation tests, but "Archived Results" doesn't seem to have recent versions of SSL clients listed? nameConstraints=critical, DNS Certification Authority Authorization: https://en.wikipedia.org/wiki/DNS_Certification_Authority_Au... : > Registrants publis…
Name Constraints has been around at least since 1999 (RFC 2459).
I'm not sure why CAA is brought up here. I guess it is somewhat complementary in "reducing" the power of CAs, but it defends against good CAs misissuing stuff, not limiting the power of arbitrary CAs (as it's checked at issuance time, not at time of use).