I need to modify or delete and then recreate an existing letsencrypt/certbot flat domain certificate to include specific subdomains.
The subdomains are all pointed to external sites using DNS CNAME records.For example Sub.SiteA.com resolves to Siteb.com
Where I am getting confused is where the multi-domain certificate need to be. So is it on the Source server in the example above Sub.SiteA.com or is it on the Destination server?
So which scenario is correct and best practise from below:
I don't really follow. When using a CNAME there's just one server at play here (ignoring DNS itself): there's just a single IP address in the DNS, the IP address for site B. For sub.siteA.com you have a CNAME and not an A DNS resource record, so there's nothing pointing to an IP address directly for sub.siteA.com. Only through the CNAME and that one is pointing to siteB. So the siteA server never comes into play.
So I don't really understand where this question comes from? Maybe I don't understand you properly.
Its my understanding that with DNS A records you can only use an IP address but with CNAME you can use a Text Name or IP.
I have run some tests and SSL complains that the Server Certificate does not include the domain. However, it doesnt say if that certificate is on the Source or the Destination just that the domain in question is not valid within the existing certificate.
The actual Error is "NET::ERR_CERT_COMMON_NAME_INVALID" and the URL in the browser shows the Sub.SiteA.com address.
The advanced Error text is:
This server could not prove that it is sub.siteA.com ; its security certificate is from siteB.com . This may be caused by a misconfiguration or an attacker intercepting your connection.
So how do I prove sub.siteA,com cert is from siteB.com ?
Do you really have full authority/ownership of both domains?
If so why would you not just obtain one certificate for SiteA and another for SiteB?
This approach would be transparent to the end user.
My2Cents
That's correct, an A RR (resource record) should contain an IP address as value.
That's incorrect. A CNAME RR may only contain a DNS name (the "canonical name" or another CNAME forming a chain ultimately leading to a "canonical name").
The IP address to which the CNAME ultimately points to, needs to be serving the correct certificate. Due to the CNAME for Sub.SiteA which is pointing to the SiteB server and not to the SiteA server IP address, site B needs to be serving the certificate.
It sounds like you are trying to centralize your certbot certificates in one system.
But they need to be used in various systems (with different IPs and possibly locations).
This approach would work against you and creates an unnecessary complication.
You should, if possible, have each system handle it's own certificates (for all expected HTTPS connections coming to it).
[regardless of how they got there - CNAME or not; in this respect, DNS is not relevant to TLS.]
