centerclick / feedback

Issues, Bug Reports, and Feature Requests
7 stars 0 forks source link

HTTPS support #20

Closed dave4445 closed 2 years ago

dave4445 commented 2 years ago

It would be nice if this was automatic using certbot, but installing a cert manually should probably be supported too.

sgrayban commented 2 years ago

Oh this would be nice... I use a wildcard SSL cert so being able to use SSL would be really nice!!!

srob1 commented 2 years ago

I have an intermediate and root CA that I use to generate certs for internal devices. I would love to be able to load a device cert and intermediate and root CA certs and enable https access and disable http access.

dave4445 commented 2 years ago

Starting to look into this... initial plan would include choice of: Lets Encrypt HTTP-01, Lets Encrypt DNS-01, Manually enter a cert/key.

HTTP-01 would require inbound internet access DNS-01 would require dynamic DNS update access Manually entering would be annoying...

Other options to consider?

srob1 commented 2 years ago

I not familiar with Lets Encrypt HTTP-01 and Lets Encrypt DNS-01. We generate our own certs. We maintain a root CA and an intermediate CA. The root CA signs the intermediate CA's cert. The intermediate CA issues all device certs. I normally load the CA certs and the device cert into the devices that we have that support SSL certs for HTTPs. I'm guessing that's your manual entering option. For example, on my FortiGate, in Chrome in the FortiGate UI I go to Certificates, select Local Cert or CA Cert, and then there is an upload button. When I click that a file selection box pops up that lets me select a certificate file on my disk to send to the FortiGate. I believe my HP printers and cisco switches work the same way.

dave4445 commented 2 years ago

https://letsencrypt.org/docs/challenge-types/

dave4445 commented 2 years ago

My concern with manually entering is it's cumbersome and a manual process that must repeatidly occur before each expiration. Manual config would require 2 peices of data: 1) private key and 2) the cert chain, generally both delivered in PEM format, but it's error prone.

srob1 commented 2 years ago

It's not really manual, in the sense that you're not typing it in. It comes from a file, so either you transfer the file via http or https or you could theoretically cut and paste since the PEM file is ascii text.

The reason to support that is it's completely generic and agnostic to where the certs came from.

People typically get their certs from some public certificate authority. In my case, since the bulk of my devices are internal to my network, and not Internet facing, I generate my own certs using my own certificate authority because I am not protecting a public interface with the certificate. I have a lot of internal devices protected with ssl certs and can't get commercial certs for them since they use private addresses.

I don't think the Lets Encrypt mechanisms would work for my use case.

sgrayban commented 2 years ago

Most web people know how to install a PEM file because every SSL provider also sends or directs the end user on how to install them. So I would would rather stick with this format for SSL.

sgrayban commented 2 years ago

BTW never had a error when uploading or installing any SSL PEM file... the only way that could happen if you don't copy the PEM contents correctly but that is fixable in 99.99999999% of those cases.

srob1 commented 2 years ago

I agree. Historically certificate authorities have always provided their certs in files. The automated certificate things is relatively new. It also has many limitations/requirements that won't work for everyone. In particular, it seems geared towards public webservers.

sgrayban commented 2 years ago

Dave is also assuming that everyone is connecting the NTP to the public face which shouldn't be considered as most Stratum 1 NTP servers are for intranet use. PEM should be the default way to add a SSL cert.

dave4445 commented 2 years ago

Agree, HTTP method only makes sense for public exposed hosts, this will likely be very infrequent, but if it is the case its the easest method by far. DNS is useful if you're using a public hostname but not public HTTP, this isn't that hard to setup and while also not frequent, can be done securely if you have DDNS availble. Again very easy if it matches your usecase. Both of these once setup are zero maintence.

The manual upload is needed for all other cases, however it requires someone to activly do something every expiry period. if you can make the first two methods work that's great, however that's not always the case.

For manual, I'm going to see if I can allow scp of them as scp is currently blocked and I don't really want to have to copy/paste to the ssh session.

sgrayban commented 2 years ago

So why not use /etc/hosts.allow and allow the admin to specify a ip block that would be allowed ?

dave4445 commented 2 years ago

docs: https://centerclick.com/ntp/docs/https demo: https://demo.centerclick.com/

sgrayban commented 2 years ago

You rock dave!!!

srob1 commented 2 years ago

looks great. can't wait to give it a try. have a cert all ready to go.

dave4445 commented 2 years ago

1.27

sgrayban commented 2 years ago

working like a charm!!!! https://clock.borgnet.us/