Don't use SANS for token?

[respencer]

I don't know if this is a bug or if I'm missing something. We have 2 CDN servers that have the same domains on them for load balancing.

I've used getssl successfully in the past om them, but now it's using the SAN domain names to look for well-known tokens and failing with a 404 (it's random whether it's going to be pointing to itself or the other server when making that query). It should only be using the actual servers hostname for that.

Can someone please advise on whether I should filing this as a bug or if there's some setting I can use to disable this behavior?

[timkimber]

Hi @respencer

Just to check my understanding, you are running getssl something like this: ./getssl www.domain.com

and your getssl.cfg file holds something like this: SANS=cdn1.domain.com, cdn2.domain.com

and you're using http-01 validation (i.e. copy the challenge token to the .well-known directory), and getssl is checking cdn1.domain.com/.well-known/challenge-token which doesn't exist and so the check is failing?

If so, can you post the debug log - I think it should be copying the challenge to all servers (i.e. www.domain.com, cdn1.domain.com and cdn2.domain.com) and checking all servers, so it appears something isn't working.

[respencer]

Thank you @timkimber

Okay, I realize now that what I wanted doesn't make sense as the individual domains do need to be verified.

The headscratcher is why this used to work and now doesn't.

Changing you example to be a bit clearer. There's 2 CDN servers: cdn1.domain.com & cdn2.domain.com

cdn1.domain.com:SANS="cdn.domain.com, download.domain.com, rsync.domain.com"

cdn2.domain.com:SANS="cdn.domain.com, download.domain.com, rsync.domain.com"

So the same. I'm on cdn1 and run getssl, according to the apache logs everything is 200, but getssl dies with 404.

On cdn2 I do the same thing and get the same error. Check and the tokens are where they are supposed to be on each server.

I then ran repeat manual tests using curl and have now figured out that cdn1 getssl is always trying to find the token on cdn2, and cdn2's getssl is always trying to find the token on cdn1.

[githubRover]

@respencer The Lets Encrypt servers need the same response from any server which might respond to its challenges.

So, if I understand your setup correctly, when LE sends a challenge for download.domain.com your CDN may route it to either server (cdn1 or 2) so each one must be capable of responding correctly.

If you started at server CDN1 you might sometimes get lucky if your CDN routed the LE challenge back to it. That may be why it worked earlier.

So, what to do. Often, CDN's will terminate the inbound https request from the client and they offer a way to setup certs within the CDN. That provides https between the client and the CDN.

Then, if you want https between your server and the CDN you setup a cert for cdn1.domain.com and cdn2.domain.com individually from each of those servers. That is, run getssl on CDN1 requesting a cert for cdn1.domain.com.

Sorry if I misunderstand your setup. Using actual domain names allows much better evaluation.

[timkimber]

Hi @respencer

I'm not sure how to do this without either

1. following @McQgit suggestion and having cdn1.domain.com and cdn2.domain.com
2. or changing getssl to support more than one ACL location for a domain in the SANS list

I think I can do something simple to support (2) if it would be useful as I'm sure there's been a previous issue opened about CDN certificates - just let me know if you want me to do this.

[respencer]

I'm not sure how to do this without either

1. following @McQgit suggestion and having cdn1.domain.com and cdn2.domain.com
2. or changing getssl to support more than one ACL location for a domain in the SANS list

I think I can do something simple to support (2) if it would be useful as I'm sure there's been a previous issue opened about CDN certificates - just let me know if you want me to do this.

Thank you @timkimber and @McQgit for you suggestions. Unfortunately I'm not permitted to give out the real server names.

@timkimber, I'd appreciate it in you could add support for more than one ACL as suggested above please.

I managed to eventually manually force an update via getssl 2 days ago, but only due to things lining up again so that it could work.