I forget if there are any existing tests of G_TLS_CERTIFICATE_INSECURE, but if not then you could also keep the old certificate around to test that against (when the gnutls version is new enough).

Thanks for reporting this. I'll look into this soon.

(Note: Gnutls 3.6.2 is a development release, not a stable release. The version numbers are confusing. Just making sure you know.)

I can fix the G_TLS_CERTIFICATE_INSECURE errors easily enough, with this change:

diff --git a/tls/tests/files/ssl/client.conf b/tls/tests/files/ssl/client.conf
index be59460..2ba2c77 100644
--- a/tls/tests/files/ssl/client.conf
+++ b/tls/tests/files/ssl/client.conf
@@ -1,7 +1,7 @@
 # Client
 
 [ req ]
-default_md              = sha1
+default_md              = sha256
 utf8                    = yes
 string_mask             = utf8only
 prompt                  = no
diff --git a/tls/tests/files/ssl/server-intermediate.conf b/tls/tests/files/ssl/server-intermediate.conf
index d899a0f..103f50d 100644
--- a/tls/tests/files/ssl/server-intermediate.conf
+++ b/tls/tests/files/ssl/server-intermediate.conf
@@ -1,7 +1,7 @@
 # Server
 
 [ req ]
-default_md              = sha1
+default_md              = sha256
 utf8                    = yes
 string_mask             = utf8only
 prompt                  = no
diff --git a/tls/tests/files/ssl/server.conf b/tls/tests/files/ssl/server.conf
index 6a98029..76b62f1 100644
--- a/tls/tests/files/ssl/server.conf
+++ b/tls/tests/files/ssl/server.conf
@@ -1,7 +1,7 @@
 # Server
 
 [ req ]
-default_md              = sha1
+default_md              = sha256
 utf8                    = yes
 string_mask             = utf8only
 prompt                  = no

and then regenerating the certificates.

But I don't understand where the G_TLS_CERTIFICATE_BAD_IDENTITY is coming from.

It corresponds to GNUTLS_CERT_UNEXPECTED_OWNER, which shouldn't be happening.

(In reply to Dan Winship from comment #1)
> I forget if there are any existing tests of G_TLS_CERTIFICATE_INSECURE, but
> if not then you could also keep the old certificate around to test that
> against (when the gnutls version is new enough).

There's currently no tests for this. Should be easy to add one. I'll do that as part of this bug.

(In reply to Michael Catanzaro from comment #4)
> It corresponds to GNUTLS_CERT_UNEXPECTED_OWNER, which shouldn't be happening.

I'm stumped on this one.

G_TLS_CERTIFICATE_BAD_IDENTITY corresponds to GNUTLS_CERT_UNEXPECTED_OWNER *or* to g_tls_certificate_gnutls_verify_identity() failing. In particular, perhaps gnutls_x509_crt_check_hostname() now returns FALSE for insecure certificates even if the hostname matches?

Or did you mean you're still getting it even after regenerating the certificate?

If you add "#define GTLS_GNUTLS_DEBUG" to the top of gtlsbackend-gnutls.c you'll get lots of debug output, including the line number of any non-"success" return statement that gets hit.

(In reply to Dan Winship from comment #8)
> Or did you mean you're still getting it even after regenerating the
> certificate?

Yeah. We switched gnome-build-meta over to the freedesktop SDK, which has GnuTLS 3.6.1. I was able to reproduce the reported bug:

"Error code 34 is G_TLS_CERTIFICATE_INSECURE | G_TLS_CERTIFICATE_BAD_IDENTITY."

After changing the digest algorithm and regenerating the certificates, I'm now getting just 2: G_TLS_CERTIFICATE_BAD_IDENTITY.

> If you add "#define GTLS_GNUTLS_DEBUG" to the top of gtlsbackend-gnutls.c
> you'll get lots of debug output, including the line number of any
> non-"success" return statement that gets hit.

I'll try that, thanks. I'll also try upgrading to GnuTLS 3.6.2 just in case it might be related to https://gitlab.com/gnutls/gnutls/issues/347 (though I don't think it is).

(In reply to Dan Winship from comment #8)
> If you add "#define GTLS_GNUTLS_DEBUG" to the top of gtlsbackend-gnutls.c
> you'll get lots of debug output, including the line number of any
> non-"success" return statement that gets hit.

Didn't help much.

(In reply to Dan Winship from comment #7)
> G_TLS_CERTIFICATE_BAD_IDENTITY corresponds to GNUTLS_CERT_UNEXPECTED_OWNER
> *or* to g_tls_certificate_gnutls_verify_identity() failing. In particular,
> perhaps gnutls_x509_crt_check_hostname() now returns FALSE for insecure
> certificates even if the hostname matches?

Good call: g_tls_certificate_gnutls_verify_identity() is indeed the problem. gnutls_x509_crt_list_verify() works fine after switching from sha1 to sha256 in the config files.

I spent a while looking at https://gitlab.com/gnutls/gnutls/commit/27e61632048c156a578e688a7d3b2cfc277848c2 because our server certificate specifies only an IP address in subjectAltNames, which was valid in GnuTLS 3.5 but not in 3.6. Removing that wasn't enough to fix this, though. Still investigating.

(In reply to Michael Catanzaro from comment #10) 
> Removing that wasn't enough to fix this, though.

Wrong, I failed to notice that the line number on the assertion failure had changed. ^_^  Removing the subject alt name makes the hostname check for "server.example.com" pass. But then of course the next check for the IP address fails. So to make this work, I figure we need to include both in the subject alt name, like this in the server.conf file:

[ alt_names ]
IP.0                    = 192.168.1.10
dirName                 = req_dn

Which gives this result (from 'certtool --certificate-info --infile=server.pem'):

Subject Alternative Name (not critical):
	IPAddress: 192.168.1.10
	directoryName: CN=server.example.com,DC=EXAMPLE,DC=COM

But if I do that, verification for "server.example.com" fails once again.

Irritatingly, 'certtool --verify --infile=server.pem --load-ca-certificate=ca.pem --verify-hostname=server.example.com' accepts this certificate, which is weird since I would expect --verify-hostname to have the same behavior as gnutls_x509_crt_check_hostname().

Found the solution:

[ alt_names ]
IP.0                    = 192.168.1.10
DNS.0                   = "server.example.com"

Final problem is that /tls/connection/simultaneous-async-rehandshake and /tls/connection/simultaneous-sync-rehandshake are both broken. I'm guessing that's caused by https://gitlab.com/gnutls/gnutls/issues/158.

(In reply to Michael Catanzaro from comment #13)
> Final problem is that /tls/connection/simultaneous-async-rehandshake and
> /tls/connection/simultaneous-sync-rehandshake are both broken. I'm guessing
> that's caused by https://gitlab.com/gnutls/gnutls/issues/158.

Maybe not, we're getting GNUTLS_E_INVALID_REQUEST, but the error conditions added there return GNUTLS_E_UNAVAILABLE_DURING_HANDSHAKE.

Failure is here in _gnutls_epoch_new:

	/* If slot out of range or not empty. */
	if (slot == NULL)
		return gnutls_assert_val(GNUTLS_E_INVALID_REQUEST);

	if (*slot != NULL)
		return gnutls_assert_val(GNUTLS_E_INVALID_REQUEST);

It's the second check that's failing (slot not empty).

Bugzilla is my liveblog.

d161a6323fe83ab4213643bfa838deb46caf3d27 is the first bad commit
commit d161a6323fe83ab4213643bfa838deb46caf3d27
Author: Nikos Mavrogiannopoulos <nmav@redhat.com>
Date:   Fri Sep 15 09:29:30 2017 +0200

    constate: simplified allocation of epochs
    
    Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>

:040000 040000 be4d0bf50e24e986d021ae0b84cbf8ad8871cfa2 6393ae6a3a08931ff28444fb2a0c0fbde16f5a74 M	lib

The following fix has been pushed:
d217a26 tests: Bring back check for old GnuTLS rehandshaking bug

Created attachment 370974 [details] [review]
tests: Bring back check for old GnuTLS rehandshaking bug

This reverts commit 2ef2af4ecd6bf06bc7000d7e13caf72a2eac7448.

Adapted to check for our new rehandshaking bug!

Reported https://gitlab.com/gnutls/gnutls/issues/426, let's see what Nikos thinks about it.

(In reply to Michael Catanzaro from comment #19)
> Reported https://gitlab.com/gnutls/gnutls/issues/426, let's see what Nikos
> thinks about it.

He fixed it in https://gitlab.com/gnutls/gnutls/merge_requests/620, thanks!