7

I'm having trouble using Wget to download a file over HTTPS from ftp.gnu.org using the Let's Encrypt X3 root. The Let's Encrypt X3 is cross-certified, which means it has an issuer and its not self-signed. When using Let's Encrypt X3, Wget is failing with the error it can't find the issuer certificate even though I am trying to root trust in the Let's Encrypt certificate.

I visited RFC 4158, Internet X.509 Public Key Infrastructure: Certification Path Building to see what the behavior should be. The document discusses in detail building paths from end-entity or subscriber certificates to CA roots and trust anchors. Its what one would expect.

However, Section 1.3 provides terminology, and it defines trust anchors:

  • Trust List: A list of trust anchors.

  • Trust Anchor: The combination of a trusted public key and the name of the entity to which the corresponding private key belongs.

  • Trust Anchor Certificate: A self-signed certificate for a trust anchor that is used in certification path processing.

  • "Trust Anchor Certificate" and the definition that demands "self-signed" means we cannot root trust in a subordinate certificate, like the Let's Encrypt X3 root that's been cross-certified.

My question is, why did the RFC do that? Why are we forced to use a self-signed certificate as an anchor, and include unneeded portions of the PKI that only serve to complicate path building and increase attack surface?

Community
  • 1
  • According to [Let's Encrypt](https://letsencrypt.org/certificates/) the X3 certificates aren't roots but are intermediates, signed by the X1 root and an ISRG root. That doesn't answer your question about the RFC, of course :-) – garethTheRed Oct 15 '17 at 06:43
  • 1
    Related to but not answered at https://unix.stackexchange.com/questions/398167/wget-cannot-validate-https-ftp-gnu-org . Note that roots are conventionally defined to be selfsigned; if an anchor is (allowed to be) not selfsigned then it is not a root (but is an anchor). – dave_thompson_085 Oct 16 '17 at 02:47
  • Could you add the error message from wget? (I suspect that we're dealing with a very specific wget issue here and not a general PKI issue.) – StackzOfZtuff Nov 05 '17 at 16:08

2 Answers2

3

This is one of those tricky subtle wordings. The full meaning of the RFC may not be obvious on the first reading. From your question (emphasis mine):

Trust Anchor: The combination of a trusted public key and the name of the entity to which the corresponding private key belongs. Trust Anchor Certificate: A self-signed certificate for a trust anchor that is used in certification path processing.

A trust store serves two purposes:

  1. Establish that all signatures generated by this public key should be trusted, and
  2. Bind the public key to a name (usually an LDAP Distinguished Name (DN) is defined in RFC2253)

Some corollaries of that are:

  • All signature performed by that key will be trusted, including certificate issuances.
  • Because you are explicitly marking it as Trusted, This key can not be revoked through normal methods - the only way is to manually remove it from your trust store.

The subtly here is that the RFC allows you to pin either a certificate, or a public key directly, however if you pin a certificate then it needs to be a root certificate. The RFC gives some justification here:

1.5.1. Hierarchical Structures

A hierarchical PKI, depicted in Figure 1, is one in which all of the end entities and relying parties use a single "Root CA" as their trust anchor.

From the CA's point of view, they may not want you pinning the intermediate CA because that removes their ability to revoke it if it becomes compromised: even if they publish a revocation for it, your client will ignore it.

In the case where a CA does want you to be able to use an intermediate CA as a trust anchor, I have seen them give a trust anchor both an issued certificate, and a self-signed cert for the same public key and DN. I would assume that Let's Encrypt does not do this for its intermediate CAs.

As to your actual question about wget, ftp.gnu.org, and the Let's Encrypt X3 intermediate CA, I think you have two options:

  • Find the self-signed root cert that issued Let's Encrypt X3 and add that to your trust store.
  • Figure out how to pin a public key directly. This will depend on the software / OS stack you're using and whether it supports the archaic and uncommon part of the RFC that allows a Trust Anchor to be a key and not a certificate.
Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
1

As a general assumption: if it's not self-signed; you're relying on some other entity to imbue trust; that other entity by definition becomes the anchor.

Though many implementations may trust something further down the chain, that isn't a function of PKI/x509 - it's an out-of-band trust; thus out-of-scope for the RFC.

It raises a question: why would you imbue implicit trust in an anchor, that itself doesn't have implicit trust from its issuer (it could be revoked)

CGretski
  • 151
  • 6