2 sets of wildcard and base domain certs on 1 IP address

Help
1

Hi,

I use https://github.com/skoerfgen/ACMECert as a client in my PHP code.

I’m requesting for 2 certs using 2 orders

  1. *.domainA.com (dns-01) and domainA.com (http-01)
  2. *.domainB.com (dns-01) and domainB.com (http-01)

To answer some questions first:

  • Both domainA.com and domainB.com are residing on the same IP address
  • I want to separate domainA and domainB into 2 different certificates to make clear they are not affiliated and in case the domains have to be moved to another server etc
  • I can’t do dns-01 for base domain and wildcard as submitting the 2nd DNS record overwrites the earlier one
  • long story short, order 1 works without any issues, both dns-01 and http-01 are challenged
  • basically I’m ruling out any bugs in the code as they have been in use for years, the only thing I’m doing different this time round is adding of base domains (http-01) to each cert

What happens when I submit order 2 for domainB.com is really puzzling:

Am I missing something or is this a bug? Thank you.

2

Hard to say without actual logs/error messages from Let’s Encrypt, “authz” URL’s and the actual domain names and sorts.

3

I guess my question is, does Let’s Encrypt have any policies on preferring to use SAN instead of separate certs for domains residing on the same IP? Maybe let me try to get logs from some other domains

4

No.   

5

Why is it overwritten? Can you fix it so it isn't?

6

Yes, after my OP, I did a check and found my DNS code was the culprit for overwriting, going to get it fixed. Nonetheless, the behavior I observed seems to be a bug. Verification performed on domainA, wildcard + base domain cert issued for domainB.

I would be more than happy to share the real domainA and domainB with LE staff.

7

One common cause of this is the fact that the validation server will follow redirects.

So if http://domainB.com/.well-known/acme-challenge/xx results in a 301 redirect to http://domainA.com/.well-known/acme-challenge/xx, then the latter URL will show.

If you look at the authorization URL yourself, you will also see a validation record field, which is an ordered list of HTTP requests that the validation server performed. More than one request in the list = redirects were encountered.

What is the status of the enclosing authorization then? The exceedingly likely explanation is that you are responding to the wrong challenge (or not responding to one of them at all).

It would be easier to figure this out if you were able to share the order URL. I encourage you to let the community try help you - can you possibly just run your client against an order for example.com + *.example.com?

At least with a fabricated (and guaranteed to fail) domain, we can also remove authorization reuse as a confounding variable in this problem.

1 Like
8

The template when creating a new topic in the Help category includes:

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

2 Likes
9

Thanks for the all the replies and help.

domain A in question is phuketlager.com
domain B in question is watchcottage.com

My DNS bug caused me to explore alternatives which ended up with dns-01 (*.example.com) + http-01 (example.com) method. I have since fixed the DNS bug and is now using dns-01 (*.example.com) + dns-01 (example.com).

The redirect sounds plausible, but I no longer have any logs to refer to and was not looking out for it then. As these are live domains, I also can’t afford to be messing around with them further. I will be happy to answer any questions to make sure this was not a bug. Thank you.

10

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