"Site not secure" | Self-signed Certificate?
-
I think the easiest thing is to provide us with the entire scenario. What is the computer used for? Why the weird port? Why don't you have a cert?
Weird port: 8080 is the generally accepted INSECURE secondary port. 8443 is the generally accepted SECURE secondary port. It's all random, but confusing to humans.
-
@mr-jones said in "Site not secure" | Self-signed Certificate?:
Can you prevent the formentioned error when visiting a domain server from a domain computer with a self-signed certificate? i.e. https://server:8080
I've been doing a lot of reading on it and after failing repeately at the task, I read somewhere that no matter what you'll get that error unless the certificate is from a public Certificate Authority. But I read a lot of things on the internet that aren't quite right. My brain hurts, it's Friday, and I know this group would know the right answer.
I'm wondering if I'm just doing things wrong, but before I dive into what I've tried, I wanted this question answered so I know if I need a different approach or not. Ultimately, I don't want to have to pay for an SSL, but I'll cross that road when I come to it.
You can, but you have to add the SSL cert for https://server:8080 to every certificate store on each of the computers. Hopefully all your software uses the system certificate store, but you'll want to double check.
-
@mr-jones said in "Site not secure" | Self-signed Certificate?:
Can you prevent the formentioned error when visiting a domain server from a domain computer with a self-signed certificate? i.e. https://server:8080
Yes, but it's a little difficult.
-
Either you add the self-signed certificate for every server to all your computers. That's impractical though.
-
Or you set up your own CA and add that to all your computers. Then you issue your own server certificates with your own CA and they will be trusted automatically.
You can't get or buy publicly trusted SLL certificates for any server on your LAN, only for public FQDNs/IPs.
Option 2 is what you are supposed to do. We've been planning to do it at work (linux infrastructure) but we haven't started on it yet.
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.
-
-
Let's Encrypt supports free wildcard certs - so that could be an option for internal resources that use the FQDN but are only internal - updating the cert every 90 days or less is the bigger pain - though can be scripted.
-
@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.
-
@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!
-
@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.
-
@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.
-
Here is a writeup that someone did..
https://gock.net/blog/2020/using-lets-encrypt-with-internal-web-server/
In this case they are using it for internal web servers. The reason that I normally use it is that I use LetsEncrypt for things that aren't web servers and so act the same as isolated LAN devices.
-
@scottalanmiller said in "Site not secure" | Self-signed Certificate?:
So the answer is... it depends. Do you control the computer in question? If so, you can normally add the certificate to it and it will trust it.
But if you don't want to have to install the cert for every computer that will use it, then sadly only a CA signed cert (which are free, though) will work as you need to have the browser trust it and that is the only mechanism.
Okay, so if what you are saying is true, then I'm doing it incorrectly.
I was using :8443 btw, I don't know why I used :8080 as an example.
What are the steps here?
Do I create a .p12, split out the private .key and store that on the server, then split out the public .pem and push that to all domain computers into the Trusted Root Certificates directory via Group Policy?
Or do you have to have a .crt in the mix and that's why this approach would be such a pita.
-
@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.
