From libsys at hacktivista.org  Tue May  2 16:42:06 2023
From: libsys at hacktivista.org (Felix Freeman)
Date: Tue, 02 May 2023 10:42:06 -0400
Subject: [gnutls-help] Certificate generation for HTTPS. What am I doing
 wrong?
Message-ID: <CSBVD5AX80Z5.2DMDMJJ5EM0V6@localhost.hacktivista.org>

I need to create an HTTPS certificate to communicate between hosts on my
development environment. I need to create it non-interactively, since I
expect to run this setup in the future automatically.

I've done it several times directly with OpenSSL but it's too much text
to include on an automated script to my taste. I'd rather have it
simplified, so I thought I could use certtool for this task.

When using the certtool the certificates are created smoothly. Then I
configure it on nginx and the CA certificate installed on my development
environment. Nginx is able to serve the certificates. But curl, firefox
and any other SSL enabled application reject it as unsafe.

Notice that just as of today I've done the same with an certificate
generated direcly with openssl and it works just fine. I am certain that
I'm doing it right on nginx and the installation of my CA.

The unique difference evident to me in the certificate generation is
that I'm using a password for the certificate authority key when
working directly on openssl.

I don't need the certificate to be actually safe, I only need to
simulate the conditions of communication on my development environment.

What am I doing wrong? Following, my recipe.

DOMAIN=example.org
cat <<- EOF > ca.cfg
    cn = "CA"
    ca
    cert_signing_key
    expiration_days = 3650
EOF
certtool -p --outfile /etc/ssl/private/ca.key
certtool -s --load-privkey /etc/ssl/private/ca.key --outfile /etc/ssl/certs/ca.crt --template ca.cfg
cat <<- EOF > server.cfg
    cn = "$DOMAIN"
    expiration_days = 365
    dns_name = "$DOMAIN"
    signing_key
    encryption_key
    tls_www_server
EOF
certtool -p --outfile "/etc/ssl/private/$DOMAIN.key"
certtool -q --load-privkey "/etc/ssl/private/$DOMAIN.key" --outfile server.csr --template server.cfg
certtool -c --load-privkey "/etc/ssl/private/$DOMAIN.key" --load-ca-privkey /etc/ssl/private/ca.key --load-ca-certificate /etc/ssl/certs/ca.crt --load-request server.csr --outfile "/etc/ssl/certs/$DOMAIN.crt" --template server.cfg


From ueno at gnu.org  Fri May  5 03:33:34 2023
From: ueno at gnu.org (Daiki Ueno)
Date: Fri, 05 May 2023 10:33:34 +0900
Subject: [gnutls-help] Certificate generation for HTTPS. What am I doing
 wrong?
References: <CSBVD5AX80Z5.2DMDMJJ5EM0V6@localhost.hacktivista.org>
Message-ID: <87sfcbimtt.fsf-ueno@gnu.org>

Hello Felix,

"Felix Freeman" <libsys at hacktivista.org> writes:

> I need to create an HTTPS certificate to communicate between hosts on my
> development environment. I need to create it non-interactively, since I
> expect to run this setup in the future automatically.
>
> I've done it several times directly with OpenSSL but it's too much text
> to include on an automated script to my taste. I'd rather have it
> simplified, so I thought I could use certtool for this task.
>
> When using the certtool the certificates are created smoothly. Then I
> configure it on nginx and the CA certificate installed on my development
> environment. Nginx is able to serve the certificates. But curl, firefox
> and any other SSL enabled application reject it as unsafe.
>
> Notice that just as of today I've done the same with an certificate
> generated direcly with openssl and it works just fine. I am certain that
> I'm doing it right on nginx and the installation of my CA.
>
> The unique difference evident to me in the certificate generation is
> that I'm using a password for the certificate authority key when
> working directly on openssl.
>
> I don't need the certificate to be actually safe, I only need to
> simulate the conditions of communication on my development environment.
>
> What am I doing wrong? Following, my recipe.
>
> DOMAIN=example.org
> cat <<- EOF > ca.cfg
>     cn = "CA"
>     ca
>     cert_signing_key
>     expiration_days = 3650
> EOF
> certtool -p --outfile /etc/ssl/private/ca.key
> certtool -s --load-privkey /etc/ssl/private/ca.key --outfile
> /etc/ssl/certs/ca.crt --template ca.cfg
> cat <<- EOF > server.cfg
>     cn = "$DOMAIN"
>     expiration_days = 365
>     dns_name = "$DOMAIN"
>     signing_key
>     encryption_key
>     tls_www_server
> EOF
> certtool -p --outfile "/etc/ssl/private/$DOMAIN.key"
> certtool -q --load-privkey "/etc/ssl/private/$DOMAIN.key" --outfile
> server.csr --template server.cfg
> certtool -c --load-privkey "/etc/ssl/private/$DOMAIN.key"
> --load-ca-privkey /etc/ssl/private/ca.key --load-ca-certificate
> /etc/ssl/certs/ca.crt --load-request server.csr --outfile
> "/etc/ssl/certs/$DOMAIN.crt" --template server.cfg

The recipe does look correct to me.  I was able to set up a server and
connect to it with:

gnutls-serv --x509certfile=/etc/ssl/certs/$DOMAIN.crt \
            --x509keyfile=/etc/ssl/private/$DOMAIN.key \
            --sni-hostname=$DOMAIN

gnutls-cli --x509cafile=/etc/ssl/certs/ca.crt \
           --sni-hostname=$DOMAIN \
           --verify-hostname=example.org \
           -p 5556 localhost

To further diagnose the issue I would try:

- Connect to the Nginx server with gnutls-cli, to see if/why the
  verification fails
- Compare the certs generated with OpenSSL and GnuTLS with certtool -i

Regards,
-- 
Daiki Ueno


From simon at josefsson.org  Mon May  8 15:48:39 2023
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 08 May 2023 15:48:39 +0200
Subject: [gnutls-help] guile-gnutls-3.7.12 released [stable]
Message-ID: <87fs872atk.fsf@josefsson.org>

Guile-GnuTLS provides Guile bindings for the GnuTLS library.

Project homepage:
  https://gitlab.com/gnutls/guile

The release is available here:
  https://gitlab.com/gnutls/guile/-/releases/v3.7.12

Documentation:
  https://gnutls.gitlab.io/guile/manual/
  https://gnutls.gitlab.io/guile/manual/gnutls-guile.html
  https://gnutls.gitlab.io/guile/manual/gnutls-guile.pdf

Here are the compressed sources and a GPG detached signature:
  https://ftpmirror.gnu.org/guile-gnutls/guile-gnutls-3.7.12.tar.gz
  https://ftpmirror.gnu.org/guile-gnutls/guile-gnutls-3.7.12.tar.gz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.org/order/ftp.html

Here are the SHA1 and SHA256 checksums:

e89bdcaff02235ce4fd2b6e479eff431754a5698  guile-gnutls-3.7.12.tar.gz
XTrxFXMJPeWfJYQVhy4sWxTMqd0lGosuwWQ9bpf+4zY  guile-gnutls-3.7.12.tar.gz

The SHA256 checksum is base64 encoded, instead of the
hexadecimal encoding that most checksum tools default to.

Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify guile-gnutls-3.7.12.tar.gz.sig

The signature should match the fingerprint of the following key:

  pub   ed25519 2019-03-20 [SC]
        B1D2 BD13 75BE CB78 4CF4  F8C4 D73C F638 C53C 06BE
  uid   Simon Josefsson <simon at josefsson.org>

If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.

  gpg --locate-external-key simon at josefsson.org

  gpg --recv-keys 51722B08FE4745A2

As a last resort to find the key, you can try the official GNU
keyring:

  wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
  gpg --keyring gnu-keyring.gpg --verify guile-gnutls-3.7.12.tar.gz.sig


This release was bootstrapped with the following tools:
  Autoconf 2.71
  Automake 1.16.5
  Makeinfo 7.0.3

NEWS

* Noteworthy changes in release 3.7.12 (2023-05-08) [stable]

** The gnutls-guile library can now use newer gnutls features.
It is possible to use newer GnuTLS features, such as new algorithms
and new functions, without sacrificing compatibility with older GnuTLS
implementations. The enumeration values that are not available for the
GnuTLS you build gnutls-guile against will simply be undefined. You
can check whether a function is available with `(defined? 'hmac-copy)`
(here for hmac-copy).

** Bind the HMAC and hash functions from GnuTLS.

** Correctly handle blocking writes to session record ports

Happy hacking,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20230508/41fa5aa5/attachment.sig>

From linma at cendio.se  Tue May 23 16:06:10 2023
From: linma at cendio.se (Linn Mattsson)
Date: Tue, 23 May 2023 16:06:10 +0200
Subject: [gnutls-help] What is the recommended stable GnuTLS version?
Message-ID: <309a9168-578b-7aa8-ba9d-63c517ef297a@cendio.se>

Hi,

When checking the page https://www.gnutls.org/security-new.html it's a 
bit confusing which version that is the recommended stable one. More 
precisely, the more recent tag GNUTLS-SA-2022-07-07 recommends an 
earlier version of GnuTLS (3.7.7), in contrast to the earlier tag 
GNUTLS-SA-2020-07-14 which recommends a later version of GnuTLS (3.8.0).

Adding to the confusion, we understand 3.7 to be a development branch, 
in addition to 3.8 not having released a stable version yet, e.g. 3.8.1.

To summarise, what is the recommended version currently?

Thanks in advance!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20230523/e80e14e3/attachment.html>