Tls-sni-01 documentation

lbehm · October 31, 2017, 3:06pm

Hy, after dns-01 I now want to implement tls-sni-01 in my new client.
So I found this rfc a couple of times in the search. For example the acme-divergences document states that boulder implements tls-sni-01 and not -02. Well, that sounds okay to me.

My problem is that I’m receiving only the token parameter. tls-sni-01 describes an additional n parameter (Number of tls-sni-01 iterations) that is obviously missing. And coincidentally tls-sni-02 describes only a single token again!
And now I really confused

My question is: is there an api documentation for the implementation in boulder?
Does anyone have any hidden documentation?
Or can someone point me to the implementation in the boulder source?

Osiris · October 31, 2017, 3:35pm

The Boulder divergences page refers to the draft version used. Currently it’s linking to the 7th version of the draft, but you’re using the very first one.

Much has changed, including, apparently, the removal of n.

lbehm · October 31, 2017, 3:47pm

Are you sure?
Because thats tls-sni-02 you’re referring to.

Osiris · October 31, 2017, 3:53pm

I was sure, now I'm very sure I was incorrect

Now I'm confident you're correct

lbehm · October 31, 2017, 4:08pm

Don't be too sure about that either
Maybe everyone implements tls-sni-02 and just forgot to change the name. Maybe just to confuse the russian...

Osiris · October 31, 2017, 4:19pm

I think the last remark is quite correct. See:

and more importantly: https://github.com/ietf-wg-acme/acme/pull/22

There’s a discussion about the whole version bump. It was decided not to do that.

Now we don’t have a valid tls-sni-01 documented unfortunately

lbehm · October 31, 2017, 4:35pm

Thanks for the effort @Osiris!

Following your links, I will go with this for now: https://github.com/ietf-wg-acme/acme/blob/f094e73b8a65cb1a6778e6feb1b065efe3c2831a/draft-ietf-acme-acme.md#tls-with-server-name-indication-tls-sni

cpu · October 31, 2017, 4:50pm

Indeed - as @Osiris (Thanks!) points out there isn't a draft snapshot that captures the TLS-SNI-01 challenge as it exists in Boulder. Draft-01 is close but there were changes made that weren't captured before the TLS-SNI-02 challenge replaced TLS-SNI-01 outright in Draft-02. Unfortunate side-effect of the IETF draft process and a living document

Sure! There are two functions you'll want to look at in the Validation Authority: validateTLSSNI01:

github.com

letsencrypt/boulder/blob/887d75f1e0019694ec7aab9d9a60f9da69f013db/va/va.go#L648:L660


      
          	if payload != challenge.ProvidedKeyAuthorization {
          		errString := fmt.Sprintf("The key authorization file from the server did not match this challenge [%v] != [%v]",
          			challenge.ProvidedKeyAuthorization, payload)
          		va.log.Info(fmt.Sprintf("%s for %s", errString, identifier))
          		return validationRecords, probs.Unauthorized(errString)
          	}
          
          	return validationRecords, nil
          }
          
          func (va *ValidationAuthorityImpl) validateTLSSNI01(ctx context.Context, identifier core.AcmeIdentifier, challenge core.Challenge) ([]core.ValidationRecord, *probs.ProblemDetails) {
          	if identifier.Type != "dns" {
          		va.log.Info(fmt.Sprintf("Identifier type for TLS-SNI-01 was not DNS: %s", identifier))
          		return nil, probs.Malformed("Identifier type for TLS-SNI-01 was not DNS")
          	}
          
          	// Compute the digest that will appear in the certificate
          	h := sha256.Sum256([]byte(challenge.ProvidedKeyAuthorization))
          	Z := hex.EncodeToString(h[:])
          	ZName := fmt.Sprintf("%s.%s.%s", Z[:32], Z[32:], core.TLSSNISuffix)

and validateTLSSNI01WithZName:

github.com

letsencrypt/boulder/blob/887d75f1e0019694ec7aab9d9a60f9da69f013db/va/va.go#L530:L552


      
          	}
          
          	// Otherwise if there are no IPv6 addresses, or there was an error
          	// talking to the first IPv6 address, try the first IPv4 address
          	address := net.JoinHostPort(v4[0].String(), thisRecord.Port)
          	thisRecord.AddressUsed = v4[0]
          	certs, err := va.getTLSSNICerts(address, identifier, challenge, zName)
          	return certs, validationRecords, err
          }
          
          func (va *ValidationAuthorityImpl) validateTLSSNI01WithZName(ctx context.Context, identifier core.AcmeIdentifier, challenge core.Challenge, zName string) ([]core.ValidationRecord, *probs.ProblemDetails) {
          	certs, validationRecords, problem := va.tryGetTLSSNICerts(ctx, identifier, challenge, zName)
          	if problem != nil {
          		return validationRecords, problem
          	}
          
          	leafCert := certs[0]
          	for _, name := range leafCert.DNSNames {
          		if subtle.ConstantTimeCompare([]byte(name), []byte(zName)) == 1 {
          			return validationRecords, nil
          		}

There are also lots of open source ACME clients you could refer to that implement TLS-SNI-01. Certbot, Acme.sh, etc.

I'll see about updating the divergences document in the Boulder repo to provide a link to a more concrete description of the TLS-SNI-01 challenge implementation since there isn't a numbered draft that captures it. Thanks for raising the question!

lbehm · October 31, 2017, 5:24pm

Thank you for your helpful replies!
I will look into it.

lbehm · November 1, 2017, 11:04pm

@cpu is it possible to fix some typos in there?
A full documentation maintainable by Let’s Encrypt would be great!

cpu · November 2, 2017, 1:15pm

@lbehm Can you be more specific about where you found the typos? If it was in https://github.com/letsencrypt/boulder/blob/master/docs/acme-divergences.md then please submit a pull request to GitHub - letsencrypt/boulder: An ACME-based certificate authority, written in Go. with the fixes. If it was with https://github.com/ietf-wg-acme/acme/blob/f094e73b8a65cb1a6778e6feb1b065efe3c2831a/draft-ietf-acme-acme.md#tls-with-server-name-indication-tls-sni then please check if the typo still exists in the current draft: https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md - if it does, submit a pull request with fixes to GitHub - ietf-wg-acme/acme: A protocol for automating certificate issuance. If it only exists in the specific blob you linked then there isn't any way to fix it retroactively.

Thanks!

system · December 2, 2017, 1:23pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
Tls-sni-01 or tls-sni-02 to support now?	6	4782	April 20, 2017
Where I can read used protocol description? Issuance Tech	2	1417	May 26, 2016
Identifier Validation Challenges Issuance Tech	3	2042	November 11, 2015
2018.01.11 Update Regarding ACME TLS-SNI and Shared Hosting Infrastructure Incidents	3	72699	January 13, 2018
Acme-divergences.md - application/pkix-cert Client dev	4	844	June 5, 2019

Tls-sni-01 documentation

Related topics