I don't believe that "SANs" qualifies as misuse from a semantic standpoint. The list contains the alternative names of the subject in question.
We are off-topic and will likely get called out for it...
But saying that only proves my point.
My claim is hat everyone is saying it/using "SAN" incorrectly to the point where it is now in the definition.
So the definition is now wrong!
[and you can't use the definition as the only proof that it is correct]
My claim is that even the IETF uses the term "subject alternative nameS" in their own specifications.
From:
Subject alternative names MAY be constrained in the same manner as subject distinguished names using the name constraints extension as described in Section 4.2.1.10.
Finally, the semantics of subject alternative names that include wildcard characters (e.g., as a placeholder for a set of names) are not addressed by this specification.
From:
Restrictions apply to the subject distinguished name and apply to subject alternative names.
For multiple certs, LE allows many certs on same IP/server, certainly certs contain different domains
I have this idea, it shall work: I declare multiple virtualhost for multiple certs but server same website, like below
<VirtualHost *:443>
DocumentRoot "/htdocs/mybuilder.com"
ServerName www.mybuilder.com
ServerAlias *
SSLCertificateFile "server1.crt"
SSLCertificateKeyFile "server1.key"
</VirtualHost>
<VirtualHost *:443>
DocumentRoot "/htdocs/mybuilder.com"
ServerName www.mybuilder.com
ServerAlias *
SSLCertificateFile "server2.crt"
SSLCertificateKeyFile "server2.key"
</VirtualHost>
<VirtualHost *:443>
DocumentRoot "/htdocs/mybuilder.com"
ServerName www.mybuilder.com
ServerAlias *
SSLCertificateFile "server3.crt"
SSLCertificateKeyFile "server3.key"
</VirtualHost>
Web server with this configuration shall work? And if works, it's enough smart to know which domain requesting to delivery right SSL cert?
I mean no offense, my friend, but if you aren't familiar with SNI, I don't have much hope for the endeavor you're undertaking.
The configuration you've posted is absolutely nonsensical.
Yes, I'm really noob at this field, from beginning I just wanted to establish it to work
May you give me where to start?
Where on earth would you get that idea?
It does, and I gave you the link explaining how.
OpenSSL doesn't "have" any certs. It's a piece of software. It can be used to create certs, but those certs won't be trusted by anyone else.
I have no idea what you're asking here, but DNSSEC has nothing to do with TLS certificates.
Broken DNSSEC can prevent issuance of certificates, so it's partly related.
@Osiris, to be fair that response now seems to be taken out of context.
Since it is a response to:
Yes @danb35's response should have been better worded to pass such scrutiny.
Maybe something more like:
Adding DNSSEC has nothing to do with fixing the problem you're having with TLS certificates.
As we all should know, adding DNSSEC doesn't really add much to resolving most problems.
While having a broken DNSSEC implementation would be of concern.
I'm just replying to an IMO incorrectly made statement. A better statement would have been:
If DNSSEC wasn't a problem to begin with, adding it doesn't help.
thank all so much for helping & joining
@danb35 I read your gave link 3 times - Serving tens of thousands of domains over HTTPS with Caddy - Wiki - Caddy Community ; in fact for me, caddy is really the final solution I would research because I'm really not familiar with its configuration code, I don't know if it shall be okay and work with current settings & current web server (CentOS 7 + sentora
). From beginning of my builder, I only work with Apache, then its code is really too strange; for me it's really too complicated.
But I also see that it's using reverse_proxy
, this setting is same Apache reverse-proxy
?
@griffin seems my problem can be only solved with Reverse Proxy Guide - Apache HTTP Server Version 2.4 ???
I searched few tutorials, its purposes are only multiple web apps on different IPs or ports, not like mine: 1 web app for multiple domains (with SSL) on 1 IP + 1 port.
My web app could be not worked with multiple VirtualHost
directives
Do you have free time to help me & give more guides?
Many thanks
A reverse-proxy is a reverse-proxy.
The only real difference, and why Caddy has been recommended, is on how Caddy handles TLS connections and certs. Which is where Caddy exceeds - it can dynamically handle a very large number of certs with very little programming.
But you already read enough to know that Caddy is your best choice for that:
So, I don't really understand that question, nor the motivation behind it, given the context of this entire topic.
This is a recurring theme and seems to be an unquenchable vacuum:
You should already have more than enough information to get you started on testing/implementing a solution to your problem.
This forum is for obtaining help with questions regarding acquisition and installation of Let's Encrypt certificates. It is not an online university course in webservers 101. While we are happy to help how we can, I feel that your needs are far beyond the scope of this forum. I highly recommend diligent self-study and/or taking actual classes. Personally, at this stage I have grave concerns for anyone who attempts to use what you are developing as you do not seem to grasp even the most basic concepts.
It's worth learning--you'll find that it's far simpler than Apache's; it just does the Right Thing™ almost all the time with very little guidance. For one example, my prepackaged Nextcloud installation on FreeNAS went from over 1000 lines of web server configuration files using Apache, to under 50 lines using Caddy--and Caddy, in addition to acting as the webserver, now handles the TLS cert. Caddy does more, with far less configuration.
But the reason it's being mentioned here is that it can do exactly what you say you want to do. It will listen for HTTPS requests, and if it gets one for a domain that it doesn't already have a cert for, it will obtain a new cert in real time. The post I linked to explains how to do that.
Now, if you want to learn about Caddy, check out its docs; if you have more involved questions, the Caddy Community would be a better place to post them than here. But they, like we, are going to expect that you have at least a basic understanding of the relevant technologies, one which you seem to be lacking right now.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.