"Site not secure" | Self-signed Certificate?
-
@scottalanmiller I am confused, if you certbot or any other Lets Encrypt client, it can use DNS verification automatically without needing any server enabled externally. That's what I have been doing with CloudFlare and their API, are you doing something different?
I even apply it to current web facing servers so I don't need to open port 80 as well. -
@dbeato said in "Site not secure" | Self-signed Certificate?:
I am confused, if you certbot or any other Lets Encrypt client, it can use DNS verification automatically without needing any server enabled externally.
No, not all of them. They have ones that require manual intervention. The ones that handle internal servers.
-
@dbeato said in "Site not secure" | Self-signed Certificate?:
That's what I have been doing with CloudFlare and their API, are you doing something different?
I even apply it to current web facing servers so I don't need to open port 80 as well.We don't always have CloudFlare. If we control the server and not the DNS hosting, it can be complicated.
-
@scottalanmiller said in "Site not secure" | Self-signed Certificate?:
@dbeato said in "Site not secure" | Self-signed Certificate?:
That's what I have been doing with CloudFlare and their API, are you doing something different?
I even apply it to current web facing servers so I don't need to open port 80 as well.We don't always have CloudFlare. If we control the server and not the DNS hosting, it can be complicated.
True. But even Godaddy has APIs for this now, lol. If SlowDaddy can do it, I'd suspect that some of the others do as well.
-
@dafyre said in "Site not secure" | Self-signed Certificate?:
@scottalanmiller said in "Site not secure" | Self-signed Certificate?:
@dbeato said in "Site not secure" | Self-signed Certificate?:
That's what I have been doing with CloudFlare and their API, are you doing something different?
I even apply it to current web facing servers so I don't need to open port 80 as well.We don't always have CloudFlare. If we control the server and not the DNS hosting, it can be complicated.
True. But even Godaddy has APIs for this now, lol. If SlowDaddy can do it, I'd suspect that some of the others do as well.
That "someone" has API access doesn't matter if you don't have any access to the provider. Sometimes you only have the server.
-
@scottalanmiller Okay, but lets see can we request API access to any of them yes. But doing manual work its just not great. Are you saying that you control just a subset of servers and the rest is on their own and the customer cannot give you DNS access even as a request? or is it trying not to get involved with the other vendors or DNS hosting provider?
-
@dbeato said in "Site not secure" | Self-signed Certificate?:
@scottalanmiller Okay, but lets see can we request API access to any of them yes. But doing manual work its just not great. Are you saying that you control just a subset of servers and the rest is on their own and the customer cannot give you DNS access even as a request? or is it trying not to get involved with the other vendors or DNS hosting provider?
Right, we manage X and not Y and cannot get the API because we have to request through a human for a change. If the ONLY thing we can touch is the server, and the server cannot be exposed over port 80, we need to do it manually.
-
@scottalanmiller said in "Site not secure" | Self-signed Certificate?:
@jaredbusch said in "Site not secure" | Self-signed Certificate?:
@pete-s said in "Site not secure" | Self-signed Certificate?:
@scottalanmiller said in "Site not secure" | Self-signed Certificate?:
@pete-s said in "Site not secure" | Self-signed Certificate?:
You can't get or buy publicly trusted SLL certificates for any server on your LAN, only for public FQDNs/IPs
We get them. It's just more effort.
Please elaborate Scott!
Yes, please.
Sure, you just have to do it via the DNS TXT process. The server has to be able to reach out, it can't be totally isolated from the Internet (unless you want to move the files around manually) but it verifies that you own the name without needed to provide a file. We do this for some clients all of the time. It's a pain and cannot be automated, so you need a human to get involved from time to time to make it work. But it works.
That is more than getting a cert for everything on your LAN. That is also giving everything your on LAN a valid FQDN, and thus also valid internal DNS records, or NAT reflection etc, for said traffic.
-
@dbeato Stated exactly what I was thinking.
Note: this not meant to disregard (that would be silly & pointless) the specifics that Scott has mentioned. In other words, one size (or solution) does not necessarily fit all (scenarios).But I use Caddy in a Dockerized setup for a server that isn’t publicly available (not wide open) as it doesn’t need to be nor do I want it to be).
In my case I use dnsmadeeasy and their API. Does require DNS (records) access/ability to manage some records.All of which adds “complexity” (not much, but some), enough that I wouldn’t recommend it if the tech involved was new for someone (if so, home lab it first) for anything in production.
-
@jaredbusch said in "Site not secure" | Self-signed Certificate?:
@scottalanmiller said in "Site not secure" | Self-signed Certificate?:
@jaredbusch said in "Site not secure" | Self-signed Certificate?:
@pete-s said in "Site not secure" | Self-signed Certificate?:
@scottalanmiller said in "Site not secure" | Self-signed Certificate?:
@pete-s said in "Site not secure" | Self-signed Certificate?:
You can't get or buy publicly trusted SLL certificates for any server on your LAN, only for public FQDNs/IPs
We get them. It's just more effort.
Please elaborate Scott!
Yes, please.
Sure, you just have to do it via the DNS TXT process. The server has to be able to reach out, it can't be totally isolated from the Internet (unless you want to move the files around manually) but it verifies that you own the name without needed to provide a file. We do this for some clients all of the time. It's a pain and cannot be automated, so you need a human to get involved from time to time to make it work. But it works.
That is more than getting a cert for everything on your LAN. That is also giving everything your on LAN a valid FQDN, and thus also valid internal DNS records, or NAT reflection etc, for said traffic.
In this particular case, we don't actually do that. It's 100% public DNS because the servers are actually public, just don't act that way to LE because they don't run web servers. So public FQDN that already exists and is used works properly. But since port 80 isn't open on the network, and we can't have a web server anyway, we have to act like it is internal.
But if you are going to do internal certs, then as certs require DNS, you have to do all that work anyway. You just have to make sure it is an FQDN so that public certs can reference it.
-
@pete-s said in "Site not secure" | Self-signed Certificate?:
I'm not sure how you set up CA on Windows AD but I believe you can. Don't know if you can use that for non-Windows appliances.
I ended up using this approach. As usual, it took a bit of reading and research along with poking at the server, but I was able to use this approach.
-
@mr-jones said in "Site not secure" | Self-signed Certificate?:
@pete-s said in "Site not secure" | Self-signed Certificate?:
I'm not sure how you set up CA on Windows AD but I believe you can. Don't know if you can use that for non-Windows appliances.
I ended up using this approach. As usual, it took a bit of reading and research along with poking at the server, but I was able to use this approach.
Awesome! Yeah, I bet it took a bit of research to get it up and running.
