1. Forum
  2. Fidonet
  3. SYNC SYSOPS

  • sbbs not creating self-signed certs

    From Nigel Reed@1:103/705 to GitLab issue in main/sbbs on Wed Aug 6 14:05:24 2025
    open https://gitlab.synchro.net/main/sbbs/-/issues/960

    Discovered by sduensin on irc.

    On my test system I removed cryptlib.key and ensured no ssl.cert

    In scfg > System > Advanced Security turned on self-signed cert then exited scg while saving.

    After running sbbs the cryptlib.key file was created, however the ssl.cert was not.

    This seems to mimic the same behavior that sduensin saw.
    --- SBBSecho 3.29-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Wed Aug 6 17:11:39 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/960#note_7470

    Just starting sbbs isn't enough for a self-signed cert to be created, a TLS session (e.g. initiated by a remote TLS client connection) is required before the self-signed cert will be created. This is by (Deuce's) design.
    --- SBBSecho 3.29-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Scott Duening@1:103/705 to GitLab note in main/sbbs on Wed Aug 6 17:22:50 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/960#note_7471

    How can that happen if the TLS versions of the services refuse to start without a certificate?
    --- SBBSecho 3.29-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Nigel Reed@1:103/705 to GitLab note in main/sbbs on Wed Aug 6 17:27:19 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/960#note_7472

    That's ridiculous. Where's this documented? I didn't see it.

    The problem is, it seems that letsyncript may not run if there's no ssl.conf file which I was going to look into as a separate issue. sduensin ended up touching the file and then it seems to run, even if it was just an empty file. I dunno. I think maybe a ticket to Deuce may be in order. It does sound a bit convoluted and shouldn't be if a sysop just wants to get up and running.
    --- SBBSecho 3.29-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Nigel Reed@1:103/705 to GitLab note in main/sbbs on Wed Aug 6 17:35:23 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/960#note_7473

    ```
    8/6 19:34:09 web Secure Web Server listening on socket 192.168.168.1 port 443 8/6 19:34:09 web Web Server thread started
    8/6 19:34:09 web 0008 HTTPS [192.168.168.2] Connection accepted on 192.168.168.1 port 443 from port 55476
    8/6 19:34:09 web 0008 HTTPS [192.168.168.2] Session thread started
    8/6 19:34:09 web Failed to open/read TLS certificate: /sbbs/ctrl/ssl.cert
    8/6 19:34:09 web Creating self-signed TLS certificate
    8/6 19:34:09 web Creating self-signed TLS certificate
    ```

    OK, I see it now. Definitely needs to be pointed out if it's not.
    Also, why is it logged twice?
    --- SBBSecho 3.29-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Nigel Reed@1:103/705 to GitLab note in main/sbbs on Wed Aug 6 17:38:22 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/960#note_7474

    https://wiki.synchro.net/config:ssl.cert

    states

    "Synchronet can automatically create a self-signed ssl.cert file upon startup, if it does not already exist." so either the wiki is wrong, or the software is wrong.
    --- SBBSecho 3.29-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Wed Aug 6 17:39:59 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/960#note_7475

    Maybe you're thinking of the private key file?
    --- SBBSecho 3.29-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Wed Aug 6 17:40:24 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/960#note_7476

    The wiki is currently documented the old/previous behavior.
    --- SBBSecho 3.29-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Wed Aug 6 17:46:50 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/960#note_7477

    The behavior was changed, I think, in commit 976801798b81e5215a286a91c4d75908fede25fe
    --- SBBSecho 3.29-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Nigel Reed@1:103/705 to GitLab note in main/sbbs on Wed Aug 6 17:59:22 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/960#note_7479

    That sort of makes sense. Where are these cached files stored? I've never noticed them.
    --- SBBSecho 3.29-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Nigel Reed@1:103/705 to GitLab note in main/sbbs on Wed Aug 6 18:03:29 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/960#note_7480

    I think the problem is that there seems to be a bit of a issue.
    It seems he cannot get letsencrypt to create a cert unless ssl.cert already exists
    for ssl.cert to exist it has to be created as a self-signed cert
    Which means this has to be enabled in scfg
    and then you have to connect to the https port
    and then you'll have to go info scfg and turn off self-signed certs
    then you'd have to run letsyncript

    Unless, as sduensin appears to have done, an empty ssl.cert is sufficient, which case letsyncript.js should probably either create it itself, or just continue if there isn't one.

    Of course, he was also able to find his account number in the firewall log so it may have been successful at some point but wouldn't renew for some reason. I think it would take deeper debugging.
    --- SBBSecho 3.29-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Wed Aug 6 18:13:32 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/960#note_7482

    You mean the private key? I think the caches you're referring to are in memory, not files.
    --- SBBSecho 3.29-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Wed Aug 6 18:14:29 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/960#note_7483

    You don't have to turn off self-signed certs.
    --- SBBSecho 3.29-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Wed Aug 6 18:17:02 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/960#note_7484

    That setting is just to prevent the potential race condition that exists (or existed) when updating the LetsEncrypt signed cert and the sbbs would create a self-signed cert at the same time. To prevent that possible scenario, that option can be turned off (so sbbs will *never* create a self-signed cert).

    I don't know why letsyncrypt.js would require an ssl.cert file to begin with. Perhaps it makes an HTTPS connection to letsencrypt.org?
    --- SBBSecho 3.29-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Wed Aug 6 18:19:32 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/960#note_7485

    I think (by looking js_socket.c) that a self-signed cert should be created as needed for outbound TLS (e.g. HTTPS) sessions as well.
    --- SBBSecho 3.29-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Scott Duening@1:103/705 to GitLab note in main/sbbs on Wed Aug 6 19:30:30 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/960#note_7488

    Finding my account number didn't help... Turns out I didn't enter it properly into the INI file. The module went ahead and made a new one after I 'touch'ed the cert file.
    --- SBBSecho 3.29-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab issue in main/sbbs on Wed Aug 6 21:49:04 2025
    close https://gitlab.synchro.net/main/sbbs/-/issues/960
    --- SBBSecho 3.29-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Novedades:

Servidor de Quake 3 Arena Online! - Conectate a ferchobbs.ddns.net, puerto 27960 y vence con tu equipo!