Hi,

After the following commands:

fossil init test.fossil
fossil open test.fossil
fossil ssl-config load-cert --filename /path/to/cert.pem /path/to/privkey.pem
(fossil ssl-config shows)
OpenSSL-version:   OpenSSL 3.0.0 7 sep 2021  (0x030000000)
OpenSSL-cert-file: /usr/local/openssl/cert.pem
OpenSSL-cert-dir:  /usr/local/openssl/certs
SSL_CERT_FILE:
SSL_CERT_DIR:
ssl-ca-location:
ssl-identity:
ssl-cert:
ssl-cert-file:     /path/to/cert.pem
ssl-key-file:      /path/to/privkey.pem

fossil server --port 443 --tls test.fossil

Connecting to the domain on Firefox warns The certificate is not trusted because it is self-signed. and links to the Fossil certificate.

The instructions on the wiki are quite clear but I may have missed or misunderstood a step. Is this outcome expected?

Thanks, Jesse

(Also, thanks for the quick response on my previous post regarding load-certs)

Are you saying you are no longer using a self signed cert?

Are you saying you are no longer using a self signed cert?

The built-in one was replaced by an certificate file, but:

Connecting to the domain on Firefox warns The certificate is not trusted because it is self-signed. and links to the Fossil certificate.

So Firefox is apparently still showing the built-in one, which was ostensibly replaced.

Correct.

Edge also reports: NET::ERR_CERT_AUTHORITY_INVALID, so ssl-config is not working as expected.

Who signed your cert?

  openssl x509 -in cert_file -text

Might be helpful as well.

Certbot (Let's Encrypt). I've used the cert for https tests for a web application successfully so I know they are valid and work (but maybe certs are not designed to be used for cross purposes?).

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:1d:23:36:d9:47:ad:0e:54:9b:37:f3:a7:ca:ae:5e:7c:7b
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Let's Encrypt, CN = R3
        Validity
            Not Before: Jan  8 16:51:00 2022 GMT
            Not After : Apr  8 16:50:59 2022 GMT
        Subject: CN = jessemeyer.org
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:af:44:e5:0a:dd:24:d6:02:8e:1d:77:46:40:38:
                    7d:2f:e4:8e:ea:10:61:ef:c4:4f:e6:2e:30:59:11:
                    37:6d:ca:94:42:9a:84:89:19:df:c4:e4:f7:b0:60:
                    0d:71:a8:52:4c:36:e5:5a:bf:7e:50:74:38:ad:3f:
                    31:89:6a:5f:7a:e7:b3:56:fd:47:e1:37:ad:d5:30:
                    5d:56:a7:6d:3a:1d:ac:57:62:60:d1:79:b5:55:b0:
                    2f:ad:21:d8:53:21:85:29:16:8d:9d:55:1e:88:49:
                    5d:99:99:2b:8f:4e:a5:dd:71:e0:20:09:dd:89:d9:
                    c1:4c:3f:ae:81:9a:f5:12:6f:35:f6:6a:7e:fe:a2:
                    89:57:b8:98:5c:99:d9:8f:8a:26:94:3c:e7:dc:fd:
                    0c:b8:fe:36:8d:7f:b3:e2:de:07:69:05:e0:18:df:
                    fc:b9:9f:71:ed:1a:bb:ba:0a:a2:37:55:00:ef:c2:
                    06:c3:54:d2:d6:89:13:c9:ca:e6:6d:64:c4:ac:bd:
                    9b:1d:d7:e7:e8:a9:2a:81:bc:b6:83:4f:a9:fa:51:
                    0f:2e:70:b8:10:39:22:3b:02:65:8e:13:14:27:61:
                    01:e2:a8:0f:d0:4a:d4:56:89:1d:28:97:f8:17:58:
                    58:3b:12:49:c5:22:71:a2:ee:6f:19:21:11:d6:b9:
                    a4:3b
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                DF:EF:04:0A:D9:22:EC:15:B2:21:B4:D9:80:02:FD:7C:F8:2B:AE:48
            X509v3 Authority Key Identifier:
                keyid:14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6

            Authority Information Access:
                OCSP - URI:http://r3.o.lencr.org
                CA Issuers - URI:http://r3.i.lencr.org/

            X509v3 Subject Alternative Name:
                DNS:jessemeyer.org
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1
                  CPS: http://cps.letsencrypt.org

            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : DF:A5:5E:AB:68:82:4F:1F:6C:AD:EE:B8:5F:4E:3E:5A:
                                EA:CD:A2:12:A4:6A:5E:8E:3B:12:C0:20:44:5C:2A:73
                    Timestamp : Jan  8 17:51:00.914 2022 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:0B:D6:B5:D7:C7:CB:0A:1C:49:6E:A5:6A:
                                B4:76:AD:B5:C7:36:36:37:36:B1:CA:57:DA:74:C6:D3:
                                2F:66:11:30:02:20:07:38:4D:F3:FC:70:22:28:5B:CE:
                                D6:AF:4B:8E:5C:7C:95:56:5B:8D:32:33:62:0A:D5:C2:
                                9F:43:07:79:B1:15
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 29:79:BE:F0:9E:39:39:21:F0:56:73:9F:63:A5:77:E5:
                                BE:57:7D:9C:60:0A:F8:F9:4D:5D:26:5C:25:5D:C7:84
                    Timestamp : Jan  8 17:51:00.898 2022 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:21:00:87:2E:3D:E5:1C:8A:09:5E:DC:F5:A4:
                                5B:E9:10:70:75:BD:A9:85:46:16:1C:BF:7C:F8:1E:25:
                                FB:64:F0:96:23:02:20:54:6B:F9:D8:5D:D2:9B:4C:F4:
                                11:DC:5C:2A:33:54:E3:1E:13:A1:09:E7:D6:A4:70:40:
                                CD:29:AE:83:14:19:77
    Signature Algorithm: sha256WithRSAEncryption
         77:34:f0:96:65:e0:aa:17:18:5c:43:d2:9e:30:ca:2c:5f:1b:
         ef:5d:b6:da:cf:c5:f7:dd:1c:db:d2:f0:a0:e8:ef:27:1a:ea:
         8b:73:6a:b4:b7:ab:fc:d3:40:00:ba:8e:e5:f5:86:75:a6:b4:
         59:7a:68:d7:87:06:8c:dd:f9:34:45:9a:8e:2b:69:32:98:74:
         7f:9d:d5:1a:6d:86:f1:cb:b3:7a:de:1c:f0:23:dc:68:1b:bf:
         16:f8:3b:3e:25:95:5a:15:b8:b7:28:8b:d2:67:b9:e3:c7:cb:
         79:b5:18:75:40:aa:de:6d:25:6a:7c:bb:d2:cd:bd:d9:ee:7f:
         78:0f:76:b9:4b:db:00:6b:9f:6d:0e:29:23:38:08:99:7b:9c:
         97:15:06:fd:b3:f6:66:1b:13:be:e4:da:62:0b:58:2f:5f:b7:
         de:f6:44:42:79:51:3f:97:9d:41:04:7e:94:cc:97:3c:ae:0c:
         98:ee:1a:1d:4a:62:6e:62:03:06:63:ec:11:ea:5c:51:2c:b0:
         59:79:55:d9:c3:fe:6f:08:70:68:36:e3:dc:5d:e8:88:36:5b:
         7f:fa:f3:eb:e3:7c:4c:8d:05:e5:89:2e:aa:bc:04:c7:1c:ef:
         1a:a0:e4:e9:91:b0:01:86:de:12:8b:6b:bc:4f:d1:fd:6b:09:
         d6:0e:00:aa
-----BEGIN CERTIFICATE-----
MIIFITCCBAmgAwIBAgISBB0jNtlHrQ5Umzfzp8quXnx7MA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMjAxMDgxNjUxMDBaFw0yMjA0MDgxNjUwNTlaMBkxFzAVBgNVBAMT
Dmplc3NlbWV5ZXIub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
r0TlCt0k1gKOHXdGQDh9L+SO6hBh78RP5i4wWRE3bcqUQpqEiRnfxOT3sGANcahS
TDblWr9+UHQ4rT8xiWpfeuezVv1H4Tet1TBdVqdtOh2sV2Jg0Xm1VbAvrSHYUyGF
KRaNnVUeiEldmZkrj06l3XHgIAndidnBTD+ugZr1Em819mp+/qKJV7iYXJnZj4om
lDzn3P0MuP42jX+z4t4HaQXgGN/8uZ9x7Rq7ugqiN1UA78IGw1TS1okTycrmbWTE
rL2bHdfn6Kkqgby2g0+p+lEPLnC4EDkiOwJljhMUJ2EB4qgP0ErUVokdKJf4F1hY
OxJJxSJxou5vGSER1rmkOwIDAQABo4ICSDCCAkQwDgYDVR0PAQH/BAQDAgWgMB0G
A1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1Ud
DgQWBBTf7wQK2SLsFbIhtNmAAv18+CuuSDAfBgNVHSMEGDAWgBQULrMXt1hWy65Q
CUDmH6+dixTCxjBVBggrBgEFBQcBAQRJMEcwIQYIKwYBBQUHMAGGFWh0dHA6Ly9y
My5vLmxlbmNyLm9yZzAiBggrBgEFBQcwAoYWaHR0cDovL3IzLmkubGVuY3Iub3Jn
LzAZBgNVHREEEjAQgg5qZXNzZW1leWVyLm9yZzBMBgNVHSAERTBDMAgGBmeBDAEC
ATA3BgsrBgEEAYLfEwEBATAoMCYGCCsGAQUFBwIBFhpodHRwOi8vY3BzLmxldHNl
bmNyeXB0Lm9yZzCCAQMGCisGAQQB1nkCBAIEgfQEgfEA7wB1AN+lXqtogk8fbK3u
uF9OPlrqzaISpGpejjsSwCBEXCpzAAABfjrQqzIAAAQDAEYwRAIgC9a118fLChxJ
bqVqtHattcc2Njc2scpX2nTG0y9mETACIAc4TfP8cCIoW87Wr0uOXHyVVluNMjNi
CtXCn0MHebEVAHYAKXm+8J45OSHwVnOfY6V35b5XfZxgCvj5TV0mXCVdx4QAAAF+
OtCrIgAABAMARzBFAiEAhy495RyKCV7c9aRb6RBwdb2phUYWHL98+B4l+2TwliMC
IFRr+dhd0ptM9BHcXCozVOMeE6EJ59akcEDNKa6DFBl3MA0GCSqGSIb3DQEBCwUA
A4IBAQB3NPCWZeCqFxhcQ9KeMMosXxvvXbbaz8X33Rzb0vCg6O8nGuqLc2q0t6v8
00AAuo7l9YZ1prRZemjXhwaM3fk0RZqOK2kymHR/ndUabYbxy7N63hzwI9xoG78W
+Ds+JZVaFbi3KIvSZ7njx8t5tRh1QKrebSVqfLvSzb3Z7n94D3a5S9sAa59tDikj
OAiZe5yXFQb9s/ZmGxO+5NpiC1gvX7fe9kRCeVE/l51BBH6UzJc8rgyY7hodSmJu
YgMGY+wR6lxRLLBZeVXZw/5vCHBoNuPcXeiINlt/+vPr43xMjQXliS6qvATHHO8a
oOTpkbABht4Si2u8T9H9awnWDgCq
-----END CERTIFICATE-----

As long as the fossil server is at jessemeyer.org (which is in your list of subject alt names) it should work.

What URL are you using for accessing the fossil server?

If you are using https://localhost/..., it should complain. Something about cert is not valid for localhost. You should get the same error using anything that is not https://jessemeyer.org/...

Silly question but do you have to start fossil as root to bind to port 443? If so it should change user once it finishes binding. I don't know when the cert is read, but is it readable to the user that fossil becomes?

Also IIRC when running as root it chroots, is the cert available in the new root? I wonder if this is a case of a missing error message when reading the cert file fails. The failure makes it fall back to the builtin. (From a comment Stephen made in another thread, I assume it is read before the chroot and user id change but....)

When you connect to fossil using the browser, do the certificate details match the cert in the code:

Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number:
            6a:c3:9a:e2:64:93:35:84:44:ff:c8:4c:1b:f3:c3:02:36:96:fd:13
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, ST = NC, L = Charlotte, O = Fossil-SCM, CN = Fossil
        Validity
            Not Before: Dec 27 11:31:56 2021 GMT
            Not After : Dec 27 11:31:56 2121 GMT
        Subject: C = US, ST = NC, L = Charlotte, O = Fossil-SCM, CN = Fossil
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
...

with no subject alt name.

Thanks for the assistance!

What URL are you using for accessing the fossil server?

I access the (remote) server at https://jessemeyer.org. I have it up now for you and others to temporarily access.

Silly question but do you have to start fossil as root to bind to port 443?

Yes.

but is it readable to the user that fossil becomes?

This I don't know, as this was not mentioned in the wiki article, but likely not. Were this the case, no error nor warning message were provided.

Also IIRC when running as root it chroots, is the cert available in the new root?

How would I verify this?

When you connect to fossil using the browser, do the certificate details match the cert in the code

Yes, they are Fossil's self signed cert.

Does the same thing happen with a brand new fossil repo?

Could you setup a new repo but don’t do the self signed thing - use your real cert.

This is exactly what I did, actually. See the steps I took in the first post. I started a new repo, told Fossil to use my real certs, and it is in fact not using them at all.

Ah, my mistake. Sorry.

Does it make a difference if Fossil starts on the default port of 8080, but with TLS enabled?

Can you show us the permissions of the cart and key with ls -l?

Does it make a difference if Fossil starts on the default port of 8080, but with TLS enabled?

Not that I can tell. fossil server --port 8080 --tls test.fossil

gives the same response.

Can you show us the permissions of the cart and key with ls -l?

Both are: lrwxr-xr-x 1 root wheel

Huh...

Does the permission string really start with 'l'? That indicates it's a link and not a file. We need the permissions on the file.

If it is a link, try using the full path to the real file.

Certbot by default places symbolic links of their certs in their /live subdirectory. They refer back to their /archive directory. I don't know why symbolic links would cause issues here -- my home grown webserver uses the symbolic links fine. In any case, I tried ssl-config to the original files and the behavior is the same, unfortunately.

I've tried testing with the revision 82c62e5f8dcef605 to no avail, unfortunately.

It’s not a problem per se, but we need to know the permission of files pointed by the symlink.

-rw-r--r-- 1 root wheel for the cert and full chain files. -rw------- 1 root wheel for the private key files.

John Rouillard (rouilj) on 2022-01-09 19:00:41:

Silly question but do you have to start fossil as root to bind to port 443?

Not a silly question. All processes must normally be (or have) root to bind to ports < 1024.

You can disable this on Linux by setting a per-process capability, eg:

setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/fossil

or on FreeBSD for all processes with:

sysctl net.inet.ip.portrange.reservedhigh=0

--
Dan Shearer
dan@shearer.org
Dig Fossil

been doing some digging.....

the following is set in the database:

ssl-cert-file:     /path/to/cert.pem
ssl-key-file:      /path/to/privkey.pem

though in func ssl_init_server in http_ssl.c the settings above do not seem tobe used in setting up SSL so it always falls back to the self signed cert that is embedded with Fossil.

the only ssl setting that is looked at it: line 730if( (zTlsCert = db_get("ssl-cert",0))!=0 ){`

The only use of db_get("ssl-cert-file") and db_get("ssl-key-file") are in the printing of the config ./fossil ssl-config

hope this helps.

P.S

in sslctx_use_cert_from_mem may need to add https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_add_extra_chain_cert.html

after SSL_CTX_add_extra_chain_cert to load the rest of the cert chain from the cert in memory

would try this out, but need to go to sleep

Does it make a difference if the key and cert are cat’d together?

My test case...

$ fossil init test.fossil
$ fossil server -tls test.fossil
Listening for TLS-encrypted HTTPS requests on TCP port 8080

This shows the certificate bundled with Fossil, which has an expiration date long into the future.

Then I copied a self signed certificate I use with stunnel on Windows and told Fossil to use it:

fossil server --tls-cert-file stunnel.pem test.fossil

Of course I still see the self signing warning, but when I review the certificate, I see the subject name, issuer, and expiration are all what I expect. Thu, 17 Mar 2022 18:16:27 GMT

correct, then method you tired does work....though the issue is when setting the tls certs as config settings as per the OP

fossil init test.fossil
fossil open test.fossil
fossil ssl-config load-cert --filename /path/to/cert.pem /path/to/privkey.pem

fossil server --port 443 --tls test.fossil

Right, next for me to try. I'll have to separate out my key and cert.

Update...

$ fossil ssl-config load-cert --filename ../cert.pem ../privatekey.pem
$ fossil ssl-config
OpenSSL-version:   LibreSSL 3.5.0  (0x020000000)
OpenSSL-cert-file: /etc/ssl/cert.pem
OpenSSL-cert-dir:  /etc/ssl/certs
SSL_CERT_FILE:
SSL_CERT_DIR:
ssl-ca-location:
ssl-identity:
ssl-cert:
ssl-cert-file:     /home/jerry/fossil-repos/cert.pem
ssl-key-file:      /home/jerry/fossil-repos/privatekey.pem
exception:         10.7.6.54
$ fossil server --tls
Listening for TLS-encrypted HTTPS requests on TCP port 8080

Does indeed show the Fossil self sign cert

the issue is that load-cert cmd line is placing the files or paths in to the database config table under ssl-cert-file and ssl-key-file

though the code only checks the setting ssl-cert so there is a mismatch in code paths...the cert and key that is set by load-cert is never used.

see post... https://fossil-scm.org/forum/forumpost/048c16b1294c0515

this can be fixed, the question is:

which setting combo do we want to use....

ssl-cert has a comment that this is a pem file that contains cert and key which is not set by command load-cert

load-cert command populates ssl-cert-file and ssl-key-file

ssl_init_server currently looks for ssl-cert which is not set...

It looks like I have the same failure with this as well...

ssl-identity: /home/jerry/fossil-repos/stunnel.pem

what are you seeing here ?

That it uses the inbuilt fossil certificate and omits the certificate I pointed the setting to.

hummmm.....more digging needed, I have an hour now to investigate, if I find anything else will post back.

https://fossil-scm.org/forum/forumpost/32638b8456

I have a fix for this on the following branch.

https://fossil-scm.org/home/info/c2562490d491a656

I was able to repo the issue and this fix allows my certs to be used as expected. (I used certs from a ca that I use internally)....

Would be great if others could try on their setup's who had issues.

So I have noticed, this fix, fixes the cert issue when running from an open repo.

fossil ui --tls and fossil server --tls

however, this does not fix fossil server --tls repo.fossil yet... looking in to this

Here is some working code in https://fossil-scm.org/home/timeline?r=tls-server-fix&m&c=c2562490d491a656

I am now running this checkout out on my personal server and it seems to be working...

You will need to reload your cert so that is is stored correctly

fossil ssl-config load-cert --filename /path/to/cert.pem /path/to/privkey.pem

then

fossil server --port 443 --tls test.fossil

A bit of new code was needed and a few things moved around in cmd_webserver

We had a chicken or egg situation

--tls option is read and removed from argv, but then calls ssl_init_server, this function requires access to the config table in the repo database but this is not yet ready, so the fall back is to serve the self signed cert. --tls is then removed from argv which means it cannot be checked again after the repo db is available.

the code for enabling server with ssl from a cert that is loaded using load-cert is now split in to two parts.

1. check if --tlsor --tls-cert-file is set and store the values
2. move the call to enabled ssl after the repo database has been opened

please give it a try to confirm the fix works

p.s the method I came up with seems to be the simplest way without bigger changes to the options parsing logic. If there is a better way, improvements please do post

I tend to agree, although I managed to get this to work on the tls-serevr-fix branch and using it for a few days, the changes required felt like a bit of a hack.

cert-load felt unnatural. Specifying the cert and key on the command line felt better and that is what I ended up using.

+1 from me.

on the plus side, attempting this fix helped me get stuck in to the code base :)...

Other interface changes while I was at it:

• The --tls and --ssl options are now removed from the "fossil server", "fossil ui", and "fossil http" commands. The server enters TLS mode if and only if a --cert is specified.

• The --tls-cert-file option is renamed to be just --cert.

• The --pkey option specifies the private key if the private key. Or the private key can appended to the cert.

• Use "--cert unsafe-builtin" to get the built-in self-signed cert for testing.

Changes now on trunk.

Thank you for these valuable changes.

Thanks. These altogether appear to have fixed the problem!