Some clients have issues connecting to the server

Reported by ~alexwennerberg for gemini://flounder.online

Clients that are known to have issues:

Assigned to
3 years ago
3 years ago
No labels applied.

~adnano 3 years ago

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

~alexwennerberg 3 years ago*

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

~alexwennerberg 3 years ago

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

~adnano 3 years ago

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?

~adnano 3 years ago

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


~adnano 3 years ago

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

~adnano 3 years ago

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.

~alexwennerberg 3 years ago

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


~adnano 3 years ago

Did you delete the old certificates?

~alexwennerberg (edited) 3 years ago*


~adnano 3 years ago

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?

~oppen 3 years ago

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.

~adnano 3 years ago

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.

~adnano 3 years ago

Ah I think I know what the problem is:


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.

~alexwennerberg (edited) 3 years ago*

Great, glad you got it figured out! :)

~adnano 3 years ago*

~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.

~adnano 3 years ago

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

~alexwennerberg (edited) 3 years ago*

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

~adnano 3 years ago

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

~adnano 3 years ago

Any progress?

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

~alexwennerberg 3 years ago

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

~oppen (edited) 3 years ago*

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.

~adnano REPORTED FIXED 3 years ago


Register here or Log in to comment, or comment via email.