Unfortunately I am unable to test any of these clients, so I'm not sure what the cause is. I have some theories though:

• The problem is caused by a bug in Go's TLS library
• The problem is caused by a bug in the TLS library used by these clients
• Downgrading to TLS v1.2 might resolve the issue
• Setting ClientAuth: RequestClientCert is causing the issue, but without that we won't be able to get client certificates

Bullet 4 was my guess as well. I’m going to try and find a desktop client that has this issue

Got a report that this issue occurs in asuka as well, that might make testing easier as it’s an open source desktop client

That's odd. I just cloned asuka and compiled it, and I can connect to gemini://flounder.online just fine. Perhaps this is because it uses the Rust native-tls crate, which uses the native TLS implementation of the system it is on, and my TLS implementation happens to work fine.

I really think this is the fault of some TLS implementation. Perhaps we should ask the mailing list for help tracking down the issue?

Molly brown, another Go server, also sets RequestClientCert in tls.Config, so I don't think that that is the problem here.

https://tildegit.org/solderpunk/molly-brown/src/branch/master/main.go#L49

Maybe the problem is that their TLS libraries expect the Common Name or Issuer field to be present in the certificate.

I added a Subject field to CertificateOptions so that you can specify the Common Name:

server.CreateCertificate = func(hostname string) (tls.Certificate, error) {
	return gemini.CreateCertificate(gemini.CertificateOptions{
		Subject: pkix.Name{
			CommonName: hostname,
		},
		DNSNames: []string{hostname},
		Duration: 760 * time.Hour,
	})
}

Please try to do this using the latest commit (go get git.sr.ht/~adnano/go-gemini@master) and let me know if it resolves the issue.

Just implemented that change -- still seems to have issues. Here is more detail from a client author on the issue:

https://git.sr.ht/~oppen/tva

Did you delete the old certificates?

Yep

openssl s_client -showcerts -connect flounder.online seems to be working on my machine. The CN (common name) field is present.

~oppen Could you try testing your client again?

I do get CN populated now with OpenSSL, but it still also has: Verification error: unable to verify the first certificate

The Android client is still producing the same error.

This is somewhat difficult for me to debug, as I can't reproduce the openssl Verification error on my machine.

What version of openssl are you using?

Perhaps we should post the issue on the mailing list. Maybe someone will be able to help.

Ah I think I know what the problem is:

https://tildegit.org/solderpunk/gemcert#user-content-key-types

The resulting certificates will be even smaller, and many consider them more secure than ECDSA (or, more precisely, ECDSA using the NIST standard curves, which are the only ones widely supported). These are ideal certificates for use with Gemini, but unfortunately they are not yet as widely supported as ECDSA. If you use one of these certs for your server, be aware that some clients (including most mobile clients) will be unable to access them. Hopefully this situation will change in the near future. For the time being, these certs are still useful for use as client certificates if your own client and a particular application server you want to use both support ED25519.

It looks like some clients might not support ED25519 certificates, which is what I used for go-gemini. That could explain why a lot of clients do not work.

I'll add an option to use ECDSA certificates instead. Hopefully that fixes the issue.

Great, glad you got it figured out! :)

~alexwennerberg Could you try the latest changes: go get git.sr.ht/~adnano/go-gemini@9571629

You shouldn't need to modify any existing code. ECDSA certificates will be used by default. You will need to delete the existing certificates, though.

Did you delete the old certificates? openssl says that flounder.online is still using Ed25519 certificates.

I thought I did, but I think I messed it up. I’ll check later today

You need to delete the certificates before restarting the server, otherwise the server will have a cached copy of the certificates.

Any progress?

I'd like to resolve this ticket, but can't until I am sure that the problem is no longer happening.

Looks like it's working! :) Thanks for your help!

Confirmed here on Ariane too! Investigating this got me started on the tls/certs side of things which I'd been avoiding so it's been a plus from my perspective. Thanks both.

Great!