💾 Archived View for gemi.dev › gemini-mailing-list › 000352.gmi captured on 2024-03-21 at 17:26:30. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
I just encounted this issue with my Gemini server (running GLV-1.12556) and caused it to stop receiving requests. Diagnosing the issue, I found it was most likely caused by a request to an area requiring a client certificate, only the client certificate did NOT have a subject field. The Gemini protocol specification does NOT state what must be in a client certificate, and my server made the assumption that a client certificate will always have one (and did not check to see if it was missing). It will now return an error of '62' if the subject field is missing. So that brings me to my question---what *IS* the minimum we can expect to be in a client certificate? Is a client certificate without a subject field even legal? What about a missing issuer? -spc
This would be a nice thing to have standardized in the spec. I don't see why client certs need to have a subject or issuer though. As long as they are valid certs that can form TLS connections, than why not? However, it would also make sense for a service like Astrobotany that relies on the client cert Common Name to reject certs that don't have one. But that's application specific. makeworld
I think it goes without saying that at the absolute minimum a Gemini client certificate ought to be a valid x509 certificate. I did look into this at some stage and IIRC the Issuer needs to be non-empty but the Subject does not. If that is indeed the case, then I'm not sure we should mandate anything further. As makeworld said, such certificates might not be suitable for particular applications which make use of the Subject. I guess the appropriate server response there would be 61? 62 doesn't seem to apply since the certificate is technically valid. But this does make the "CERTIFICATE NOT AUTHORISED" name for 61 misleading. Perhaps it ought to be "CERTIFICATE NOT ACCEPTED"? Cheers, Solderpunk
It was thus said that the Great Solderpunk once stated: > I think it goes without saying that at the absolute minimum a Gemini > client certificate ought to be a valid x509 certificate. I did look > into this at some stage and IIRC the Issuer needs to be non-empty but > the Subject does not. I was unaware of this and (incorrectly) assumed that the issuer and subject fields would always be present. Maybe mention somewhere in the specification that servers could expect non-subject client certificates. -spc
I think that, if a server requires a subject and no subject is given, then it is sensible to say that the certificate is not authorised, in much the same way that failing to provide a username would render a traditional login unauthorised. I don't see that as misleading, and it would seem an application specific matter to get appropriate credentials from the user. Kevin On Mon, 31 Aug 2020 at 17:52, Solderpunk <solderpunk at posteo.net> wrote: > I think it goes without saying that at the absolute minimum a Gemini > client certificate ought to be a valid x509 certificate. I did look > into this at some stage and IIRC the Issuer needs to be non-empty but > the Subject does not. If that is indeed the case, then I'm not sure we > should mandate anything further. As makeworld said, such certificates > might not be suitable for particular applications which make use of the > Subject. I guess the appropriate server response there would be 61? 62 > doesn't seem to apply since the certificate is technically valid. But > this does make the "CERTIFICATE NOT AUTHORISED" name for 61 misleading. > Perhaps it ought to be "CERTIFICATE NOT ACCEPTED"? > > Cheers, > Solderpunk > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200901/8f9c d668/attachment.htm>
Sorry, that could have been me, dragonstone still generates certificates without a subject (And it won't be updated since I'm currently working on it successor). Also there should be s little information as possible stored in the client certificates since they get transmitted in the clear to avoid giving away extra data to someone who is "just" eavesdropping without messing with the connection itself (and therefore having a pretty good chance of staying undetected). Have a nice day! -? Baschdel P.s. Apologies to Sean for sending a duplicated mail, I apparently still manage to hit the wrong reply button in thunderbird On 31.08.20 02:11, Sean Conner wrote: > I just encounted this issue with my Gemini server (running GLV-1.12556) > and caused it to stop receiving requests. Diagnosing the issue, I found it > was most likely caused by a request to an area requiring a client > certificate, only the client certificate did NOT have a subject field. The > Gemini protocol specification does NOT state what must be in a client > certificate, and my server made the assumption that a client certificate > will always have one (and did not check to see if it was missing). It will > now return an error of '62' if the subject field is missing. > > So that brings me to my question---what *IS* the minimum we can expect to > be in a client certificate? Is a client certificate without a subject > field even legal? What about a missing issuer? > > -spc > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200901/f09a 0384/attachment.htm>
It was thus said that the Great Baschdel once stated: > Sorry, that could have been me, dragonstone still generates certificates > without a subject (And it won't be updated since I'm currently working > on it successor). There is no need to apologize, things happen, and in this case, my program did the wrong thing due to a misunderstanding I had about client certificates. I'm just glad the bug was found. > Also there should be s little information as possible stored in the > client certificates since they get transmitted in the clear to avoid > giving away extra data to someone who is "just" eavesdropping without > messing with the connection itself (and therefore having a pretty good > chance of staying undetected). > > Have a nice day! You too. > -? Baschdel > > P.s. Apologies to Sean for sending a duplicated mail, I apparently still > manage to hit the wrong reply button in thunderbird No harm with that either. -spc
---