Interestingly, this functions fine:

~/bin/althttpsd -root ~/jerryaries/www/ -port 1443 --cert unsafe-builtin

Notice that I am no longer using doas (which is like sudo), because I am using port 1443.

When browsing to the page, I see the expected cert warning message.

SSL_ERROR_RX_RECORD_TOO_LONG

In testing, i've seen that response when althttpd emitted some debug output over stderr.

When trying what you did i get a different result (noting that i have to run on a different port):

$ sudo ./althttpsd -root . -port 8443 --cert unsafe-builtin
...

$ curl -Iv https://nuc:8443
*   Trying 127.0.1.1:8443...
* TCP_NODELAY set
* Connected to nuc (127.0.1.1) port 8443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* error:1408F10B:SSL routines:ssl3_get_record:wrong version number
* Closing connection 0
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number

i have no idea whether curl supports self-signed certs, though. Firefox is reporting the same error your curl is:

An error occurred during a connection to nuc:8443. SSL received a record that exceeded the maximum permissible length.

Error code: SSL_ERROR_RX_RECORD_TOO_LONG

I'm running althttpd version [7f5b143be2] on OpenBSD 7.0.

That's a forum post hash, not a checkin. Althttpd has a -version flag since a few days ago:

[stephan@nuc:~/fossil/althttpd]$ ./althttpd --version
althttpd 2.0 [0ebfe204599d] 2022-01-18T04:49:55.797

i'm taking a look but currently don't currently have a suspect. Both sqlite.org and my own server (the one we are /chatting on) are using this althttpd build.

Hmmm.

i'm taking a look but currently don't currently have a suspect.

Strangely, i can reproduce it locally on my machine but it works as expected when running on my remote server. Weeeeeird.

Same althttps version, different openssl:

# Fails here with RECORD_TOO_LONG
[stephan@nuc:~/fossil/althttpd]$ ./althttpsd --version
althttpd 2.0 [0ebfe204599d] 2022-01-18T04:49:55.797, OpenSSL 1.1.1f  31 Mar 2020

vs

# Works here with self-signed cert warning
root@wanderinghorse:/jail/bin# ./althttpsd --version
althttpd 2.0 [0ebfe204599d] 2022-01-18T04:49:55.797, OpenSSL 1.1.1l  24 Aug 2021

On that remote server curl also dies because of the self-signed cert:

* SSL certificate problem: self signed certificate
* Closing connection 0
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

What does your --version string report for the openssl version?

In testing, i've seen that response when althttpd emitted some debug output over stderr.

That's almost the problem, actually: althttpd is failing because you have not specified a -user flag and it's refusing to run as root, so it sends the response out before SSL can be set up. It won't read any wire data before dropping root privileges, so it cannot send this error over HTTPS.

Adding a -user SOMEUSER flag should resolve the issue for you.

Do we need to change something so that the error message appears locally, rather than being sent over the wire to the connecting client?

Maybe in main(), after parsing all command-line options, complain and die if getuid()==0 and there is no --user option?

Maybe in main(), after parsing all command-line options, complain and die if getuid()==0 and there is no --user option?

That would definitely be more useful. It was only a fluke that i saw a flash of the "will not run as root" message before it was overwritten by firefox's built-in error page.

i'll make that change in just a bit - Sean and i are currently debugging his problem in the libfossil /chat.

That's a forum post hash, not a checkin. Althttpd has a -version flag since a few days ago:

$ pwd && ./althttpd --version
/home/jerry/fossil-repos/althttpd
althttpd 2.0 []

For some reason the hash version of althttpd is absent.

$ openssl version
LibreSSL 3.5.0

The version hash is inserted at build-time using a -DALTHTTPD_VERSION=... option. It is done this way because it relies on information that cannot be embedded in the source file. ("cannot" in the previous sentence means "mathematically impossible without first inverting SHA3".)

How are you building your althttpd? Are you using the supplied Makefile or are you building it yourself?

Building simply with make on OpenBSD.

Using gmake, I get the version info:

$ ./althttpd --version
althttpd 2.0 [0ebfe204599d] 2022-01-18T04:49:55.797

Building simply with make on OpenBSD.

Well that's just silly ;).

We should probably rename the makefile to GNUmakefile so that it becomes invisible to non-gmakes. The "problem" is that BSD's make is "less featureful" than gmail and lacks the $(shell) construct:

VERSION_NUMBER ?= 2.0
VERSION_HASH ?= $(shell cut -c1-12 manifest.uuid)
VERSION_TIME ?= $(shell sed -n 2p manifest | cut -d' ' -f2)

If you can suggest a way to get that working in both BSD make and gmake, we can adapt the makefile for that. What we don't yet want to do is add a full-featured configuration system like autosetup. That would currently be overkill for this tree, but has not been outright ruled out as a future possibility.

Building simply with make on OpenBSD.

Well that's just silly ;).

Please try with the latest trunk. The makefile has been extensively rewired to generate the version string dynamically in such a way that it "should" be compatible with non-GNU Makes. Looking at the diff gives some idea of why GNU make remains the King of Makes :).

Works with BSD make!

$ althttpd --version
althttpd 2.0 [6f6cf2d5a5f2] [2022-01-19T05:59:56.890]

Works with BSD make!

Great, thank you for the confirmation!