[gemini] Error validating certificates #194

New Issue

nstickney · 2020-11-01T03:01:07Z

nstickney commented

2020-11-01 03:01:07 +00:00

Try opening gemini://gus.guru. An error in the bottom statusline reads, "Cert [1] hostname does not match". Given that gus.guru is listed on circumlunar.space as a recommendation, I assume it's acting in a standard way and should load correctly?

Try opening [gemini://gus.guru](gemini://gus.guru). An error in the bottom statusline reads, "Cert [1] hostname does not match". Given that gus.guru is listed on [circumlunar.space](gemini://gemini.circumlunar.space:1965/docs/faq.gmi) as a recommendation, I assume it's acting in a standard way and should load correctly?

sloum commented

2020-11-01 04:32:50 +00:00

What you are seeing is expected behavior. When a hostname does not match the requested host the certificate is rejected as compromised and the capsule will not load.

That having been said, I visited GUS in Bombadillo and had no issues. It is possible that you visited as a certificate was being changed. Try running the following from inside bombadillo if you want to try and ignore the issue and request a new cert:

:p gus.guru

That should clear out the certificate for gus and request a new one. A caveat to doing this is that you have encountered an issue, letting you know that something may not be safe and that any cert you may get may not be trustworthy. It is up to you to decide whether you can trust a new certificate. It is still possible that a new certificate will have a host name that does not match and you will be back to square one (though that does not seem to be the case here, given I was able to do this and get a new cert).

Are you using a precompiled binary, one you compiled yourself, or from a package manager? If your version of Bombadillo was compiled with go version >= 15 there were some potential breaking api changes around TLS that will be fixed in the next update of Bombadillo, so that could also be affecting the situation.

What you are seeing is expected behavior. When a hostname does not match the requested host the certificate is rejected as compromised and the capsule will not load. That having been said, I visited GUS in Bombadillo and had no issues. It is possible that you visited as a certificate was being changed. Try running the following from inside bombadillo if you want to try and ignore the issue and request a new cert: ``` :p gus.guru ``` That should clear out the certificate for gus and request a new one. A caveat to doing this is that you have encountered an issue, letting you know that something may not be safe and that any cert you may get may not be trustworthy. It is up to you to decide whether you can trust a new certificate. It is still possible that a new certificate will have a host name that does not match and you will be back to square one (though that does not seem to be the case here, given I was able to do this and get a new cert). Are you using a precompiled binary, one you compiled yourself, or from a package manager? If your version of Bombadillo was compiled with go version >= 15 there were some potential breaking api changes around TLS that will be fixed in the next update of Bombadillo, so that could also be affecting the situation.

asdf commented

2020-11-01 10:41:27 +00:00

Hi @nstickney and thanks for the report!

I also saw this error at about the time of the report. The cert was failing name validation because "certificate relies on legacy Common Name field". This was using the latest version of Bombadillo, also confirmed that the certificate was purged before retrying. Can confirm it's working now for me too.

Hi @nstickney and thanks for the report! I also saw this error at about the time of the report. The cert was failing name validation because "certificate relies on legacy Common Name field". This was using the latest version of Bombadillo, also confirmed that the certificate was purged before retrying. Can confirm it's working now for me too.

👍 1

sloum commented

2020-11-01 13:57:30 +00:00

Thanks for the report @asdf ! I can confirm that the common name field issue has been resolved in the release branch so should be fixed as of the next release. That was a breaking change with go 15 (possibly go 14) that was pointed out to me by @makeworld a bit ago. So, hopefully we will see fewer hostname issues once this next release goes out.