• sslserver

    From Johanne Fairchild@21:1/5 to All on Sun Mar 24 10:13:21 2024
    I'm running a brand new FreeBSD 13.2-RELEASE-p10. I installed the
    pkg-package ucspi-ssl-0.99b_1. I never used it, so I don't know what to expect. Can you explain what I should do about this error?

    %sslserver 0 1031 cat
    sslserver: fatal: unable to set DH parameters

    Instead of 0 (as in bind all interfaces) I also tried an IP address, a
    hostname such as ``localhost'' et cetera. Unable to set DH parameters
    sounds like cryptography bureaucracy. The DH might stand for
    diffie-hellman. Perhaps the software doesn't know how to locate some configuration it needs? The website of the program is at

    https://www.fehcom.de/ipnet/ucspi-ssl.html

    but it doesn't seem to have documentation for a newcomer.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From vallor@21:1/5 to [email protected] on Mon Mar 25 21:49:17 2024
    On Sun, 24 Mar 2024 10:13:21 -0300, Johanne Fairchild
    <[email protected]> wrote in <[email protected]>:

    I'm running a brand new FreeBSD 13.2-RELEASE-p10. I installed the pkg-package ucspi-ssl-0.99b_1. I never used it, so I don't know what to expect. Can you explain what I should do about this error?

    %sslserver 0 1031 cat
    sslserver: fatal: unable to set DH parameters

    Instead of 0 (as in bind all interfaces) I also tried an IP address, a hostname such as ``localhost'' et cetera. Unable to set DH parameters
    sounds like cryptography bureaucracy. The DH might stand for
    diffie-hellman. Perhaps the software doesn't know how to locate some configuration it needs? The website of the program is at

    https://www.fehcom.de/ipnet/ucspi-ssl.html

    but it doesn't seem to have documentation for a newcomer.

    A quick look around shows it's a hard-to-find tool.

    Looks like step 8 in this document, which might help:

    https://github.com/meixler/installing-configuring-and-running-ucspi-ssl-sslserver

    (It's not in any of the Linux repositories I use.)

    Hope that helps.

    --
    -v

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to vallor on Tue Mar 26 00:23:51 2024
    On Mon, 25 Mar 2024 21:49:17 -0000 (UTC), vallor wrote:

    https://github.com/meixler/installing-configuring-and-running-ucspi-ssl-sslserver

    The details there mention the use of Let’s Encrypt for generating the
    cert. That’s fine for a public-access server, not so good if you just
    want to experiment privately.

    For private use, you want to create your own internal CA cert, and use
    that to sign your own internal certs. Luckily, the OpenSSL 3.x tools
    make this fairly easy to do. I have instructions here <https://gitlab.com/ldo/ssl_try_python/>.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Johanne Fairchild@21:1/5 to vallor on Wed Mar 27 18:48:17 2024
    vallor <[email protected]> writes:

    On Sun, 24 Mar 2024 10:13:21 -0300, Johanne Fairchild
    <[email protected]> wrote in <[email protected]>:

    I'm running a brand new FreeBSD 13.2-RELEASE-p10. I installed the
    pkg-package ucspi-ssl-0.99b_1. I never used it, so I don't know what to
    expect. Can you explain what I should do about this error?

    %sslserver 0 1031 cat
    sslserver: fatal: unable to set DH parameters

    Instead of 0 (as in bind all interfaces) I also tried an IP address, a
    hostname such as ``localhost'' et cetera. Unable to set DH parameters
    sounds like cryptography bureaucracy. The DH might stand for
    diffie-hellman. Perhaps the software doesn't know how to locate some
    configuration it needs? The website of the program is at

    https://www.fehcom.de/ipnet/ucspi-ssl.html

    but it doesn't seem to have documentation for a newcomer.

    A quick look around shows it's a hard-to-find tool.

    Indeed. I wonder why. Such a useful tool.

    Looks like step 8 in this document, which might help:

    https://github.com/meixler/installing-configuring-and-running-ucspi-ssl-sslserver

    This is wonderful.

    --8<---------------cut here---------------start------------->8---
    It took me a fair amount of time (and Googling, and trial-and-error,
    and even some help from Erwin Hoffman) to get ucspi-ssl sslserver up
    and running, as there are a number of nuances in the process. So, I
    thought I would document the steps that worked for me to get ucspi-ssl
    sslserver up and running to have as a reference for myself, as well as
    for others that may find this useful.
    --8<---------------cut here---------------end--------------->8---

    I'm still missing at least one step. I followed the guide above, but
    sslserver still misses a key.

    # CERTFILE="/etc/ssl/cert.pem" DHFILE="/etc/ssl/dh2048.pem" \
    sslserver -sH1 0.0.0.0 1234 cat
    1234
    sslserver: fatal: unable to load key

    The documentation mentions the KEYFILE environment variable, so I
    thought that could be it. I said

    # CERTFILE="/etc/ssl/nntp-cert.pem" \
    DHFILE="/etc/ssl/dh2048.pem" \
    KEYFILE=/etc/ssl/nntp-key.pem sslserver -sH1 0.0.0.0 1234 cat
    1234
    sslserver: fatal: unable to load key

    Same thing. Looking at the source code, the failure happens here in
    main():

    if (certchainfile) {
    switch (ssl_chainfile(ctx,certchainfile,keyfile,passwd_cb)) {
    case -1: strerr_die2x(111,FATAL,"unable to load certificate chain file");
    case -2: strerr_die2x(111,FATAL,"unable to load key");
    case -3: strerr_die2x(111,FATAL,"key does not match certificate");
    default: break;
    }
    }

    Looking at ssl_chainfile(), we find:

    int ssl_chainfile(SSL_CTX *ctx,const char *certchainfile,const char *keyfile,pem_password_cb *passwd_cb)
    {
    if (!certchainfile) return 0;
    if (!keyfile) return 0;

    if (SSL_CTX_use_certificate_chain_file(ctx,certchainfile) <= 0)
    return -1;

    SSL_CTX_set_default_passwd_cb(ctx,passwd_cb);
    if (SSL_CTX_use_RSAPrivateKey_file(ctx,keyfile,SSL_FILETYPE_PEM) != 1)
    return -2;

    if (SSL_CTX_check_private_key(ctx) != 1)
    return -3;

    return 0;
    }

    So it must be

    SSL_CTX_use_RSAPrivateKey_file(ctx,keyfile,SSL_FILETYPE_PEM)

    that's not returning 1. This is an OpenSSL procedure. The
    documentation says

    SSL_CTX_use_RSAPrivateKey_file() adds the first private RSA key found
    in file to ctx.

    Perhaps there's something wrong with my private key or something wrong
    with the file. I'm running the program as root and I did put the
    permissions to the private key as 0600. (Tried more open permissions
    too.) It's not clear what the problem with key is. Could I be using
    the wrong environment variable? Doesn't look like: main() says:

    if ((x = env_get("KEYFILE"))) keyfile = x;
    if (keyfile && str_equal(keyfile,"")) keyfile = 0;

    Who created my private key? That was certbot (from Let's Encrypt).
    Here's my private key.

    -----BEGIN PRIVATE KEY----- MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgbmsZApHJl4/qtrey gGU0SG4tAVR06Dn48Rjw4G6S65ShRANCAAQf/s6+hjKAh7L4TM27HGEK8+Jw16Kc vJ+Yw3QGHvHxmJRwyjchdUvunRM048k68UNehuLGyoSqk5tCcxh50lnQ
    -----END PRIVATE KEY-----

    Could it be that it's too small? No idea.

    (It's not in any of the Linux repositories I use.)

    Puzzling.

    Hope that helps.

    Helped immensely. Thank you!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Lurndal@21:1/5 to Johanne Fairchild on Wed Mar 27 21:59:29 2024
    Johanne Fairchild <[email protected]> writes:
    vallor <[email protected]> writes:


    # CERTFILE="/etc/ssl/cert.pem" DHFILE="/etc/ssl/dh2048.pem" \
    sslserver -sH1 0.0.0.0 1234 cat
    1234
    sslserver: fatal: unable to load key

    Run it under 'strace', find where it displays the error
    message and look just before it to see what open system
    call failed and look at the path argument to see what file
    it is attempting to open.

    $ CERTFILE=... DHFILE=... strace -o /tmp/strace.tr -f sslserver -sH1 0.0.0.0 1234 cat

    $ man strace

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Kettlewell@21:1/5 to Johanne Fairchild on Thu Mar 28 08:40:54 2024
    Johanne Fairchild <[email protected]> writes:
    SSL_CTX_use_RSAPrivateKey_file() adds the first private RSA key found
    in file to ctx.

    As it says, it’s looking for an RSA private key.

    -----BEGIN PRIVATE KEY----- MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgbmsZApHJl4/qtrey gGU0SG4tAVR06Dn48Rjw4G6S65ShRANCAAQf/s6+hjKAh7L4TM27HGEK8+Jw16Kc vJ+Yw3QGHvHxmJRwyjchdUvunRM048k68UNehuLGyoSqk5tCcxh50lnQ
    -----END PRIVATE KEY-----

    That is an ECDSA private key.

    --
    https://www.greenend.org.uk/rjk/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From vallor@21:1/5 to [email protected] on Fri Mar 29 04:53:15 2024
    On Wed, 27 Mar 2024 18:48:17 -0300, Johanne Fairchild
    <[email protected]> wrote in <[email protected]>:

    vallor <[email protected]> writes:

    On Sun, 24 Mar 2024 10:13:21 -0300, Johanne Fairchild
    <[email protected]> wrote in <[email protected]>:

    I'm running a brand new FreeBSD 13.2-RELEASE-p10. I installed the
    pkg-package ucspi-ssl-0.99b_1. I never used it, so I don't know what
    to expect. Can you explain what I should do about this error?

    %sslserver 0 1031 cat sslserver: fatal: unable to set DH parameters

    Instead of 0 (as in bind all interfaces) I also tried an IP address, a
    hostname such as ``localhost'' et cetera. Unable to set DH parameters
    sounds like cryptography bureaucracy. The DH might stand for
    diffie-hellman. Perhaps the software doesn't know how to locate some
    configuration it needs? The website of the program is at

    https://www.fehcom.de/ipnet/ucspi-ssl.html

    but it doesn't seem to have documentation for a newcomer.

    A quick look around shows it's a hard-to-find tool.

    Indeed. I wonder why. Such a useful tool.

    Looks like step 8 in this document, which might help:

    https://github.com/meixler/installing-configuring-and-running-ucspi- ssl-sslserver

    This is wonderful.

    --8<---------------cut here---------------start------------->8---
    It took me a fair amount of time (and Googling, and trial-and-error,
    and even some help from Erwin Hoffman) to get ucspi-ssl sslserver up
    and running, as there are a number of nuances in the process. So, I
    thought I would document the steps that worked for me to get ucspi-ssl
    sslserver up and running to have as a reference for myself, as well as
    for others that may find this useful.
    --8<---------------cut here---------------end--------------->8---

    I'm still missing at least one step. I followed the guide above, but sslserver still misses a key.

    # CERTFILE="/etc/ssl/cert.pem" DHFILE="/etc/ssl/dh2048.pem" \
    sslserver -sH1 0.0.0.0 1234 cat
    1234 sslserver: fatal: unable to load key

    The documentation mentions the KEYFILE environment variable, so I
    thought that could be it. I said

    # CERTFILE="/etc/ssl/nntp-cert.pem" \
    DHFILE="/etc/ssl/dh2048.pem" \
    KEYFILE=/etc/ssl/nntp-key.pem sslserver -sH1 0.0.0.0 1234 cat
    1234 sslserver: fatal: unable to load key

    Same thing. Looking at the source code, the failure happens here in
    main():

    if (certchainfile) {
    switch (ssl_chainfile(ctx,certchainfile,keyfile,passwd_cb)) {
    case -1: strerr_die2x(111,FATAL,"unable to load certificate chain
    file");
    case -2: strerr_die2x(111,FATAL,"unable to load key");
    case -3: strerr_die2x(111,FATAL,"key does not match
    certificate"); default: break;
    }
    }

    Looking at ssl_chainfile(), we find:

    int ssl_chainfile(SSL_CTX *ctx,const char *certchainfile,const char
    *keyfile,pem_password_cb *passwd_cb)
    {
    if (!certchainfile) return 0;
    if (!keyfile) return 0;

    if (SSL_CTX_use_certificate_chain_file(ctx,certchainfile) <= 0)
    return -1;

    SSL_CTX_set_default_passwd_cb(ctx,passwd_cb);
    if (SSL_CTX_use_RSAPrivateKey_file(ctx,keyfile,SSL_FILETYPE_PEM) !=
    1)
    return -2;

    if (SSL_CTX_check_private_key(ctx) != 1)
    return -3;

    return 0;
    }

    So it must be

    SSL_CTX_use_RSAPrivateKey_file(ctx,keyfile,SSL_FILETYPE_PEM)

    that's not returning 1. This is an OpenSSL procedure. The
    documentation says

    SSL_CTX_use_RSAPrivateKey_file() adds the first private RSA key found
    in file to ctx.

    Perhaps there's something wrong with my private key or something wrong
    with the file. I'm running the program as root and I did put the
    permissions to the private key as 0600. (Tried more open permissions
    too.) It's not clear what the problem with key is. Could I be using
    the wrong environment variable? Doesn't look like: main() says:

    if ((x = env_get("KEYFILE"))) keyfile = x;
    if (keyfile && str_equal(keyfile,"")) keyfile = 0;

    Who created my private key? That was certbot (from Let's Encrypt).
    Here's my private key.

    -----BEGIN PRIVATE KEY----- MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgbmsZApHJl4/qtrey gGU0SG4tAVR06Dn48Rjw4G6S65ShRANCAAQf/s6+hjKAh7L4TM27HGEK8+Jw16Kc vJ+Yw3QGHvHxmJRwyjchdUvunRM048k68UNehuLGyoSqk5tCcxh50lnQ -----END
    PRIVATE KEY-----

    Could it be that it's too small? No idea.

    (It's not in any of the Linux repositories I use.)

    Puzzling.

    Hope that helps.

    Helped immensely. Thank you!

    Hello,

    The howto I linked to has two "step 8"'s. Hmm.
    Anyway, in the second "step 8", it has you copy the cert
    from the LetsEncrypt /etc directory.

    I haven't tried it, but I think your error would be consistent
    with missing the chain certificate. If memory serves, the site cert
    and the chain cert are both in the file "fullchain.pem". Perhaps
    try copying that one instead.

    (Personally, I'd point the key- and cert-file environment variables
    at the links in the LetsEncrypt /etc directory, so that 3 months from
    now, all you have to do is run "certbot renew" to get the new cert
    installed. At that time, you'll probably have to restart sslserver
    to pick up the new files.)

    --
    -v

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From vallor@21:1/5 to All on Fri Mar 29 05:35:07 2024
    On Fri, 29 Mar 2024 04:53:15 -0000 (UTC), vallor <[email protected]>
    wrote in <uu5hfr$3e7ne$[email protected]>:

    Hello,

    The howto I linked to has two "step 8"'s. Hmm.
    Anyway, in the second "step 8", it has you copy the cert from the
    LetsEncrypt /etc directory.

    I haven't tried it, but I think your error would be consistent with
    missing the chain certificate. If memory serves, the site cert and the
    chain cert are both in the file "fullchain.pem". Perhaps try copying
    that one instead.

    (Personally, I'd point the key- and cert-file environment variables at
    the links in the LetsEncrypt /etc directory, so that 3 months from now,
    all you have to do is run "certbot renew" to get the new cert installed.
    At that time, you'll probably have to restart sslserver to pick up the
    new files.)

    Sketchy though it is, I went through the gyrations to build this hairy
    monster. Saw this in the man page for sslserver:

    $CERTCHAINFILE=path
    If set, overrides the compiled-in certificate
    chainfile name. The server presents this list of
    certificats to clients. Note: Providing
    $CERTCHAINFILE has precedence over $CERTFILE.
    Certificates in this file needs to be 'ordered'
    starting from the uppermost root certificates and
    placing your host's certificate at the end.

    So looks like you use that with the full chain file.
    --
    -v

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)