The operating system my web server runs on is (include version):
Fedora 27
I can login to a root shell on my machine, with no control panel (command-line only).
I have also tried multiple variations of the above and absolutely cannot get certbot to produce a SANS certificate. There appears to be simply no way to do this, despite people claiming that it is possible.
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Error while running apachectl configtest.
AH00526: Syntax error on line 13 of /etc/httpd/conf.d/ssl.conf:
SSLCertificateFile: file '/etc/letsencrypt/live/insurgent.info/fullchain.pem' does not exist or is empty
The apache plugin is not working; there may be problems with your existing configuration.
The error was: MisconfigurationError(āError while running apachectl configtest.\n\nAH00526: Syntax error on line 13 of /etc/httpd/conf.d/ssl.conf:\nSSLCertificateFile: file ā/etc/letsencrypt/live/insurgent.info/fullchain.pemā does not exist or is empty\nā,)
Thanks, - there was a problem with no Apache plugin installed. - I eventually managed to resolve this by un-installing and then re-installing everything, including mod_ssl, and running a command similar to that you suggested:
I do not know how relevant, or important, the preceeding wildcard is, but the lack of one in my command did not appear to cause any problems and I was finally able to generate the required certificates.
This is very important. If you have corequery.uk as domain name, you create a certificate with this name. If you use *.corequery.uk, you create a wildcard certificate, so you can use it with every subdomain of corequery.uk.
And wildcards require dns-01 - validation, so apache as authenticator can't work.
ā¦all right, - thanks. I guess, then, that I would have to use one of the wildcard plugins? - Reading the information on these I am not certain how I would go about creating a setup for Apache: the required processes appear to be incredibly involved and liable to require major changes to my webserver DNS records; on top of which subdomains are working as expected when accessed via HTTPS.
Also, as I understand it from reading the documentation, wildcard and SANS are two different things and, in the case of the latter, it functions in all respects as a wilcard, only for multiple domains, not just a single domain ā¦so would not using the wildcard also, effectively, generate three separate certificates (in addition to potentially causing issues with Apacheās lack of DNS-01 compliance)?
Similar is not equal.
All certs contain a SAN.
A single domain cert contains only one name in the SAN.
If that name was a wildcard, then with only one name you could potentially serve all your systems.
That said, (LE cert) SANs have their limits...
Entries:
Minimum = 1
Maximum = 100
But their contents can be mixed, some wildcards and some not "so wild".
Now comes the real difference:
Renewals for certs that contain even one wildcard must use/include DNS authentication.
All other certs (with zero wildcards) can also use DNS but are not required to do so and most people prefer the simplest method (HTTP).
Does that clear anything up for you?
Also:
the "lack" is with certbot; not with Apache itself.
The main question is: Do you need a wildcard certificate?
If you have 5 - 50 static domains / subdomains, the webroot- or Apache/nginx - validation may be the best solution.
I have a webservice, every customer has a subdomain, there I use a wildcard-certificate. I can add customers / subdomains, but no new certificate is required. And the customers are hidden, not listet in a CT-log.
But without a DNS-provider with an API it's not a good idea to use dns-01-validation.
I think so, - thanks; but if I remember one of the problems with a wildcard solution is that wildcard certs are primarily for situations involving subdomains, not domains; and my configuration is for the latter. - I may add subdomains at a later date but, there again, bearing in mind the āfunā I have just had tryng to get SSL virtual hosts working, maybe not.
I do not require a wildcard certificate at the moment, as I am only handling a handful of domains (if that). A webroot, or Apache solution currently works for validation, though, and I run my own BIND DNS server, plus I have full access to the registrar records for the domains. I can see your point about the domains being listed in a CT-log, but DNS lookups can be just as effective. I may still decide to use the wildcard option at some point, but that will depend on the situation with my current projects.
I think this may also needs some clarification.
Different people use different names... differently!
Some people call everything to the left of a domain = a subdomain.
Some people only call an FQDN a subdomain when it contains two (or more) periods[dots] than their "root" domain.
Let me illustrate:
[1 dot] SomeCompany.com (we can all agree) is a "root" business domain.
[2 dots] www.SomeCompany.com (we don't all always agree on this) Some say it is a subdomain, some don't.
[3 dots] www.support.SomeCompany.com (we can all agree) is a subdomain of their "root" domain.
This same "problem" (misunderstanding/disagreement) is also seen with wildcard certs.
But the hard facts about a wildcards is that they only expand the "root" domain by +1 dot.
So from the example above you can't issue a wildcard to the [1 dot] domain to cover the [3 dot] domain.
*.SomeCompany.com can't cover www.support.SomeCompany.com.
But it can cover all (allowed) [2 dot] combinations of the [1 dot] domain.
And that applies upwards...
A wildcard for a [2 dot] domain, can cover all (allowed) [3 dot] combinations of that "same" domain.
A wildcard for a [3 dot] domain, can cover all (allowed) [4 dot] combinations of that "same" domain.
ā¦
A wildcard for a [20 dot] domain, can cover all (allowed) [21 dot] combinations of that "same" domain.
...
[until you overrun the width limitations for FQDNs]
Thanks for the further clarification, and my apologies for such an extended delay in replying. To me, personally, I would always class anything like support.SomeCompany.com as a subdomain and would, consequently, secure it with a wildcard; whilst anything where the domain differs would be separate certficates or a SAN.