yes, I mean issue multiple certs but 1 cert for each different domain then use some additional codes to delivery right cert to incoming domain?
and really caddy is too heavy & complicated for my purpose
You could use it as a TLS proxy and keep your other stuff in HTTP - maybe...
[behind it]
5 Likes
Nope, the CNAME should be fine for that.
Typically yes, if you're using something like Apache. As @rg305 mentioned, you might have to use some other kind of reverse proxy if that doesn't work for you. The selection of the certificate and key comes right at the beginning of the connection, so whatever is initially accepting the connection normally needs to have access to every possibly relevant certificate and key in order to choose the right one. That could conceivably be different software from the software that answers the HTTP part of the connection, though!
5 Likes
so my case can only use reverse proxy? What's proxy I should use? Pls give me an advice, I really don't have any idea, I'm really noob at this server field. There's any proxy could be maintained automatically?
And about solution of Self-signed multiple-domain SSL certificate, seems browsers will not recognize it? And I found this link - Self-signed multiple-domain SSL certificates | Fordingbridge Contract Services - author said that self-signed cert has up to 11 domains only, this is right limit?
It's "too heavy & complicated" compared to what? Because it's far simpler to deal with than something like Apache or Nginx.
6 Likes
Because go to download page, it has too many addon, I really don't know what should be used for my case, then in their docs sections, I really could not see any page for my case
And really more important, I just want to try using default addons from apache and web server only.
Thanks
...and you apparently aren't willing to spend any time to learn (you probably don't need any of them)--which is characteristic of this entire topic. And you really need to spend quite a bit of time learning, because the questions you're asking show that you really have no idea how any of the relevant things work. For example:
- You're asking about a single certificate to cover any domain. If you understood how certificates work and what they mean, you wouldn't even be asking the question--you'd know that you do not control every domain on the Internet, and therefore can't demonstrate that control.
- You ask about self-signed certs. Sure, you can put anything you want in a self-signed cert, but no browser is going to trust it.
- You read schoen's comment suggesting that a reverse proxy might help, and conclude from that that "my case can only use reverse proxy".
If, as you say (and as appears to be the case), "I'm really noob at this server field", perhaps you shouldn't be trying to start and operate a hosting service quite yet. This is rather like a baby who can't even crawl asking about the finer points of running a marathon.
Edit: But speaking of Caddy, this post describes how simple it can be for Caddy to automatically obtain and maintain the certs for any domain it gets:
8 Likes
thank you so much for joining this thread & helping me
But perhaps you misunderstood, please try to understand that after all, absolutely I'll HAVE TO research for solving my case. But currently, I just want to find a BEST LOWEST-COST solution to fit my purpose among a lot of solutions, I was not saying I would not spend time to research; I just want to understand clearly all usable solutions to choose a best one for me. During this thread, in each post, I was researching then asked many questions (in many fields) in a post, and I always asked for possibilities & confirmations, not conclude anything.
My case is quite special, it's not test mode to try anything on it:
- My builder is in production, working perfectly without SSL
- My builder is not real hosting provider
- I'm noob at this
So I just want to understand all solutions carefully before apply anything to it. If something wrong, I scare I would not to backup to the good point.
Use CloudFlare CDN - now it's secure!
5 Likes
One note of caution: it's still important to have working HTTPS on your own ("origin") server when using Cloudflare. Even though Cloudflare will take care of the certificates and encryption for your end users' connections to Cloudflare, you should still encrypt Cloudflare's connection back to your server. Their service is great but it won't entirely solve the problem here.
6 Likes
Yeah, that was more of just a nod in the right direction a full-blown solution.
Putting more thought on this, I doubt CF alone can resolve this problem.
But using a similar in-house solution could: Use a separate dedicated reverse proxy (like Caddy) to do all the TLS. The insecure links will be only within the local LAN (or same system) and nothing else would require any modifications what-so-ever.
3 Likes
Adding onto @JamesLE's excellent advice, you can find a world of information here:
4 Likes
thank all so much for viewing, replying & helping, because I could not edit 1st post, so I update in this
Update 3: I also emailed to Wix dev team with the link of this thread since I started this thread, I don't know they view this thread or not; but they replied my emails very fast, really I also want to thank them so much for helping. And I'll recommend their platform if I have a chance personally.
And after a long conversation, Wix confirmed they're a real hosting provider; basically, they'll create a new VirtualHost for each new created site, hence they may issue each SSL cert for every domain quickly. Here's below their final message:
Thank you for getting back to us.
We know how important is for you to have some answers about how to connect domains via SSL, let me check that for you.The only ways Wix can connect a domain is using the Wix name servers or using the pointing method, you can review those methods over the following articles. [Connecting a Domain to Wix Using the Pointing Method](https://support.wix.com/en/article/connecting-a-domain-to-wix-using-the-pointing-method) [Connecting a Domain to the Wix Name Servers](https://support.wix.com/en/article/connecting-a-domain-to-the-wix-name-servers) Currently, Wix does not support third-party [SSL ](https://support.wix.com/en/article/about-ssl-and-https)certificates. All Wix sites are enabled with HTTPS, so are created with inbuilt SSL certification. We do not authenticate sites built elsewhere. Therefore, we are unable to generate [CSR ](https://help.101domain.com/ssl-certificates/what-is-a-certificate-signing-request-csr)files (SSL authentification) for domains and subdomains connected to external sites. However, as my partner said before: you can obtain an SSL certificate for your domain directly from a Certificate Authority (CA). You'll then have to configure the certificate on your web host or on your own servers if you host it yourself, but if you purchase your custom Domains through Wix, there is no need because is included already.
Update 4: an explanation in details of my case
Unlike Wix, there are many multiple VirtualHost directives for created sites, my VPS has only 1 pair of VirtualHost, like below
<VirtualHost *:443>
DocumentRoot "/htdocs/mybuilder.com"
ServerName www.mybuilder.com
ServerAlias *
SSLEngine on
SSLCertificateFile "conf/ssl.crt/server.crt"
SSLCertificateKeyFile "conf/ssl.key/server.key"
</VirtualHost>
<VirtualHost *:80>
DocumentRoot "/htdocs/mybuilder.com"
ServerName www.mybuilder.com
ServerAlias *
</VirtualHost>
This setting is working perfectly. If user has a domain usercustomdomain.com, they'll need to
- Use builder to create a site
- Fill their domain "usercustomdomain.com" in Site Settings
- In DNS manager, they create a CNAME record then point to www.mybuilder.com
After DNS updated, my builder may serve content of usercustomdomain.com flawlessly like a real hosting but in fact it has 1 domain only. But currently this setting may work with HTTP only, if access with SSL, browsers will show warning.
And if I add usercustomdomain.com to current certificate of mybuilder.com then warning disappear.
Therefore, my purpose is really simple: SSL Certificate for unlimited domains, every new site created, I'll add to cert, this is best lowest-cost solution I could think. But I searched to realize max of letsencrypt is 100, paid others are higher but still not unlimited
I'm still researching all possibilities.
And seems caddy only offers SSL cert for main domain? It has solution for my case, pls help me, many thanks
About OpenSSL, it has unlimited cert?
I also tried to enable DNSSEC on a domain, then it's unavailable; DNSSEC could handle this?
Many thanks
1 Like
Un related to resolving your problem but it is just too much for me to bear looking at... without saying something about it.
This is bad practice:
You should not (in order from above):
- define a VirtualHost without a specific port
- use an IP in a VirtualHost definition
- use ports in a ServerName definition
5 Likes
yes, thank you so much, I just checked again, it's same you said, I edited the post
so do you know about OpenSSL limitations? I could not find any where, just 1 link said that 11 is max
1 Like
Hello @PREScriptZ,
Maybe it is simple but I'm afraid that doesn't exist. RFC5280 Section 4.2.1.6 doesn't impose a limit for SANS but clients like browsers do, at least for the size of the certificate.
Just check with your browser whether you can access to these sites (you wont be able to access the second one that is using a cert with 10000 sans):
https://1000-sans.badssl.com/
https://10000-sans.badssl.com/
I think Chrome limits the cert size to 63KB and Internet Explorer limited it to 44KB but all clients would have a limit because a big certificate will slow down the connection to your site.
I recommend to visit this site, it explains it very well:
You should start thinking to create a VirtualHost per domain (or several of them per VirtualHost) and issue individual certs or max 100 SANS per certificate.
Good luck,
sahsanu
4 Likes
I can affirm that Let's Encrypt has a limit of 100 SANs per certificate.
5 Likes
I can affirm that LE has only one SAN per cert [as all certs do].
And that one SAN field can hold up to 100 FQDNs.
LOL [potato-potato]
6 Likes
The FQDNs listed under the subject alternate name (SAN) field are commonly known as subject alternative names (SANs). Potato-potato, but I get your point. 
5 Likes
Yes, and people still call new two port cable to Ethernet brouters "Cable Modems"
Although they no longer contain any "Modem" capable parts.
I guess if enough people misuse a term it becomes "correct" by that sheer force - LOL
[ignorance is bliss]
5 Likes