Setting http(s) server

H

hruodr

Now a trivial theme. I have installed, locally, many times http server. Three times a public one. One in debian,
one in ubuntu, and one in freebsd. I have the feeling, that with time it gets more difficult, not more easy.
More details to see, more complicated configuration files.

I usually need html and cgi.

Locally I tried naviserver and apache. Public only apache.

The first time, installing apache in debian, I ignored Debian's pre configuration and wrote my httpd.
With ubuntu, I tried to follow the debian pre-configuration.
With FreeBSD just edited the configuration file.

The new experience with public servers is https, to create the certificates with Let's Encrypt. The first time I tried
certbot and gave up. Then I managed to install and use dehydrated, and now I am trying uacme. The last seems
to be the most simple, but there are lots of details to care for.

How do you do? What server software you use? How do you create and renew certificates?
 
You're opening can of worms filled with many personal opinions. ;-)

If you're happy with Apache use Apache, X (where X is insert http server of choice here) might not be the most efficient solution but unless you're running a site high volume traffic it's not going to matter.

In terms of documentation (including non official) Apache HTTP Server (httpd) and Nginx or forks such as Angie and freenginx are likely your best choices.
Apache have a module for handling ACME called mod_md, I personally haven't used Apache in years but it will likely do it's job just fine. It's an option in the port for Apache HTTP Server itself
Nginx "recently" released a plugin for handling ACME (Angie have their own too), I haven't used either myself but they're probably fine. See https://ports.freebsd.org/cgi/ports.cgi?query=nginx-acme&stype=all&sektion=all

You can also use an external application, such as certbot, uacme, acme.sh, lego etc to name a few.

I personally ended up with nginx and Lego as it was pretty much straight forward with nice and clear tutorials available. With that being said, Apache might be more suitable for your setup for example.

If you're wearing your tinfoil hat be aware that it's written in Go so there's a dependency list (within Go) quite a bit longer than your shell or C-lang client. I try to stay away from Python projects as much as possible on FreeBSD as dependency list can be quite complex and the status of the ports tree is quite messy.

There are also other options out there such as Caddy with comes with its down ACME client.
 
diizzy said:
You're opening can of worms filled with many personal opinions. ;-)
Click to expand...
I wrote my experience and expressed only two opinions:

1) That it [apache] is getting more difficult.

2) uacme seems to be the most simple (compared with certboot and dehydrated).

Then I asked about your experience.
 
Without claiming to read their mind, I suspect that diizzy just means it's one of those things where lots of people have lots of opinions. There's an old saying something like, there's always more than one way to do something in Unix with the corollary that someone will think your way is stupid. I have a small website that basically duplicates the one I have hosted somewhere else. I use nginx and use certbot with letsencrypt by having a cronjob. I think I got a typical cronjob from somewhere, though if I run py311-certbot -D I see a message to add to /etc/periodic.conf to weekly_enable. But I've had it awhile, maybe when I first did it, doing it with a cronjob was from the certbot instructions at taht time, It seems the most likely reason I'd have that. I think I did use acme.sh at one point. I'm sorry, I just don't remember the details nor why I changed to certbot. I used to run it on RH then switched to a FreeBSD jail, because I'm more comfortable with FreeBSD. (It's possible that at some point I had a problem with the RH one, but again, my memory is hazy.) Sorry to be of so little help.
 
I believe the only true security is not having to trust any third party, so I haven't used a CA...For my stuff I use apache and self-sign certificates. It means that users must accept the certificate the first time though.
 
The centralised approach to https is stupid (and the fact it fails to consider internal, airgapped networks means its crooked and broken by design) but if you need to play the game to stop popular web browsers from frightening your users, then so be it.

One approach that can be entirely automated and keep dependencies down (good practice) is:
The trick is to use e.g. inetd to redirect port 80 to the special acme.sh test server, only when its running as part of a cert update. Then update the certificate used by stunnel and restart it (or just a reload signal), keeping the httpd completely undisturbed.

Note: You may need to modify acme.sh to point to tools in FreeBSD base (i.e fetch rather than curl). Typically I would just use acme-client(1) in OpenBSD base.

If your site will have heavy traffic, inetd should probably be replaced with something like relayd. Another solution is to run stunnel on your vps, forward everything through that and avoid dumb certificates on your local server entirely.
 
kpedersen said:
The trick is to use e.g. inetd to redirect port 80 to the special acme.sh test server, only when its running as part of a cert update. Then update the certificate used by stunnel and restart it (or just a reload signal), keeping the httpd completely undisturbed.
Click to expand...
Separation of tasks, but what is the win?
A simple http server will perhaps have no big latency starting, but normally inetd is not its place.

cracauer@ said:
If you post the error messages from when you ran the cert scripts we might be able to help.
Click to expand...
Thanks. No error, but wasted time. I got it with dehydrated and with uacme. With the experience I get sure with others.
Certbot disturbed me, as I remember, due to maximal intransparency, and I gave up.
 
With uacme you create a let's encrypt account with, after substituting <your-email>:

uacme --confdir /usr/local/www/Acme new <your-email>

Create and renew certs, after substituting <your-domain> and offering
/usr/local/www/apache24/data/.well-known/acme-challenge/file
with the URL http://<your-domain>/.well-known/acme-challenge/file with a script:
export SHELL=/bin/sh
export UACME_CHALLENGE_PATH="/usr/local/www/apache24/data/.well-known/acme-challenge"

if
su -m www -c '/usr/local/bin/uacme \
--confdir /usr/local/www/Acme \
--hook /usr/local/www/Acme/uacme.sh \
issue <your-domain>'
then
chown www:ssl-cert /usr/local/www/Acme/private/<your-domain>/key.pem
chown www:ssl-cert /usr/local/www/Acme/<your-domain>/cert.pem
chmod 640 /usr/local/www/Acme/private/<your-domain>/key.pem
chmod 644 /usr/local/www/Acme/<your-domain>/cert.pem
/usr/sbin/service apache24 reload
fi
Click to expand...

Just run to create a certificate and put it in root's crontab for renewal.
For experimenting put -s in the account creation and in above script.

I think, this is the simplest way, but you must care on permissions, on creating the directories,
configure the httpd first without SSL because you do not have certs, and such details.
 
It's rather late, but since you've got a public server is there any reason that you're not using caddy? With a routable ip and name it should handle this more or less automatically.
 
hedwards said:
is there any reason that you're not using caddy?
Click to expand...
I just do not know it.

I have a little experience with apache, it does what I need, it woks also together with other software.
Unfortunately looks bloated.

I just read that nginx does not support cgi out of the box, do not know how problematic may be.

Naviserver is alive and maintained, but unfortunately no FreeBSD package:

NaviServer

Tclers wiki
wiki.tcl-lang.org wiki.tcl-lang.org

About Cert: I prefer that it not be dependent of the web server. I use the certs for other things also.
That problem is more or less easily solved with dehydrated or uacme, one only needs to serve the challenge.
 
You could serve the challenge through DNS instead, automatically if your DNS setup permits that. I run a few zones through AWS Route53 and it has automation out of the box through Certbot. No need to serve challenges over my web servers at all. There's also automation for other DNS providers and RFC 2136 standard dynamic DNS update. This entails the creation of a temporary TXT record in your DNS zone to prove domain ownership.
 
bvdw78 said:
You could serve the challenge through DNS instead, automatically if your DNS setup permits that.
Click to expand...
Yes, my registrar (porkbun) offers such setup and even certificates. That has the advantage that one could get cert with
wildcard. In spite of it, I did not study enough this possibility.
 
hruodr said:
Separation of tasks, but what is the win?
A simple http server will perhaps have no big latency starting, but normally inetd is not its place.
Click to expand...
  • A simple http server may not even have SSL support.
  • A complex http / application server (e.g. Apache Tomcat) will have quite a latency
The main thing is that the acme "process" requires you to spin up a temporary web server (port 80 or experimentally via 443) with a .well_known section. I find it hacky to place these files into the main httpd server served directory (I may not even have one for example, it might all be cgi). This juggling of web servers is a little messy.

The role of inetd here is to provide that abstraction between servers. For the temporary acme spin-up, it can redirect port 80 to that (i.e 8081). Once done, it redirects back to the standard httpd. The key thing to note is that performance isn't really an issue because port 80 will rarely be used by users, so inetd (+ nc for the redirect) is fine.

Having the SSL certificate nonsense isolated and consistent in one place, rather than for each service I want to expose over SSL just reduces a bit of maintenance.
 
kpedersen said:
it can redirect port 80 to that (i.e 8081)
Click to expand...
If I want a normal http server on port 80, then I would have a problem using a dedicated server for the challenge.
Either redirect in the normal server or use something like firewall.
I do not see a big win in this procedure.
Unfortunately acme reads the challenge only from port 80.
Other solution would be to use DNS.
kpedersen said:
The main thing is that the acme "process" requires you to spin up a temporary web server (port 80 or experimentally via 443) with a .well_known section. I find it hacky to place these files into the main httpd server served directory (I may not even have one for example, it might all be cgi). This juggling of web servers is a little messy.
Click to expand...
If you do not have one, put a dedicated server there. If you have one, let the normal server offer the challenge.
The acme client need only to be able to put the challenge in the right place to be served.
 
hruodr said:
If I want a normal http server on port 80, then I would have a problem using a dedicated server for the challenge.
Either redirect in the normal server or use something like firewall.
Click to expand...
Indeed. Not a bad approach. This basically achieves the same thing. The only reason why I suggested inetd is because you can script it to only redirect if the acme challenge is currently in progress. You can absolutely achieve the same enabling and disabling a firewall rule during that same period.

hruodr said:
Unfortunately acme reads the challenge only from port 80.
Click to expand...
Indeed. Though do check out the experimental 443 (https) approach I mentioned (TLS-ALPN-01). If you have a suitable acme client, it may simplify your setup.

hruodr said:
If you do not have one, put a dedicated server there. If you have one, let the normal server offer the challenge.
Click to expand...
Yes, I try to not deal with any certificates on the on-site server. I then use the VPS or gateway server to basically perform the tasks outlined.
 
kpedersen said:
The only reason why I suggested inetd is because you can script it to only redirect if the acme challenge is currently in progress.
Click to expand...
Then one can put in inetd a server like (unfortunately not in packages):


Serving port 80 if one does not run a normal server on port 80. If one runs a normal server,
one serves the challenge with the normal server. Acme reads the challenge with http, not https.

Well, I do want always to run a normal web server, serving static files and CGI. It has multiple uses and helps a lot.
 
The problem with running a web site on port 80 is browsers will flag it. So will search engines.
Use nginx. My company and I used that but eventually switched to h2oserver which is faster, simpler, smaller, interfaces to anything and is easier to use.
I don't know why you had problems with certbot. That is easier to use than anything else. You can open port 80 when you need to renew.
 
This is my current cipher suite. It probably came from my company's use but I don't know if it's old or updated.

Code: 
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SH
 
I am using nginx + security/acme.sh. Dynamic DNS update using nsupdate to our authoritative bind nameserver at work and nginx + .well-known location for personal servers with this conf snippet
Code: 
location '/.well-known/acme-challenge' {
    default_type "text/plain";
    root /usr/local/www/acme.sh;
}
then you just tell acme.sh which directory to use for chalenge response (-w or --webroot)

There is also cooking persistent DNS validation method (doesn't require serving challenge response on domain or DNS changes on each request) which should be supported by acme.sh, but I have no personal experience there.
 
drhowarddrfine said:
The problem with running a web site on port 80 is browsers will flag it. So will search engines.
Click to expand...
You can redirect all requests except .well-known location to HTTPS. In fact, you should, because 99 % of users would not type https:// scheme if entering URL manually and not all browsers (if any?) are smart enough to try HTTPS if HTTP at port 80 doesn't respond.

Let's encrypt AFAIK also support validation over HTTPS, you just have to manually request/set up certificate for the first time to get there, because there is no HTTPS without certificate :) I think I did that somewhere some time ago because I did not want to bother with redirect exception from previous paragraph.
 
drhowarddrfine said:
Use nginx. My company and I used that but eventually switched to h2oserver which is faster, simpler, smaller, interfaces to anything and is easier to use.
Click to expand...
I was and am thinking on trying nginx. h2oserver looks interesting, I did not know it, and is in packages:


For me, naviserver is the most interesting, and have cgi, but since there is no package, I must forget.

drhowarddrfine said:
I don't know why you had problems with certbot.
Click to expand...
I did not understand how it works and did not trusted it. Long ago. But dehydrated and uacme are also simple,
when one takes time to understand them.

ondra_knezour said:
You can redirect all requests except .well-known location to HTTPS.
Click to expand...
I am doing exactly that. https without http is necessary if you use basic authentication, for example for self
programmed authentication in cgi.

ondra_knezour said:
Let's encrypt AFAIK also support validation over HTTPS, you just have to manually request/set up certificate for the first time to get there, because there is no HTTPS without certificate
Click to expand...
You will always have that problem. If you do not have certs, you must configure without ssl, get the cert, and then config ssl.
 
I don't run a webserver. But I do run an email server and need public certs so that my email server can do MTA-to-MTA TLS encrypted sessions. For me, lego is the ACME client to use since it has a built-in webserver for the ACME server to interrogate. All I have to do is leave port 80 open when I run lego at the command line. Been using lego since August 2024. No issues.
 
In /etc/rc.conf:

fcgiwrap_enable="YES"
fcgiwrap_user="www"
fcgiwrap_group="www"
fcgiwrap_socket_owner="www"
fcgiwrap_socket_group="www"
fcgiwrap_socket_mode="0660"
Click to expand...

But in spite of it:

# ls -l /var/run//fcgiwrap/
total 4
-rw------- 1 www wheel 5 Jul 27 08:54 fcgiwrap.pid
srw-rw---- 1 www wheel 0 Jul 27 08:54 fcgiwrap.sock
Click to expand...

fcgiwrap_socket_group="www" is being ignored.

The problem is sure in the rc.d script.
 
You must log in or register to reply here.
Back
Top