OCSP stapling is not a key value held in the cert nor it is restricted from any version of TLS.
This is not helpful.
Oh, I forgot:
The
ServerNamedirective is already inside of avhostconfig that limits the IP:port.
Redundancy is unnecessary and may cause problems in the future - if ever a change is required, you would have to make that change in more than one place.
This is also not helpful. And besides, it is entirely unrelated to the topic.
Unless I'm misunderstanding what you mean, I think you're mistaken, Rudy. OCSP Must-Staple (via that OID) is an extension that is both in the certificate request and the resulting signed certificate.
@rmbolger, I sit corrected, Thank you.
[I must have woke up on the wrong side of the RFC today]
So: NO, it is NOT just for TLSv1.3 (nor any specific version of TLS - it is available to ALL)
Some server implementations (for example nginx) do lazy-loading of OCSP responses. They do not obtain OCSP responses at startup, but only after the first client requested one. This doesn't play well together with must-staple, as the OCSP response must always be available, even at the very first connection.
I don't see a problem with this. My Apache does it the same way. On initial request it starts a chat with 'r3.o.lencr.org' and only after that is completed continues to setup the connection with the client.
Due to my routing this takes 350ms, but even so it works fine - there is never a problem with initial requests.
My problem is with subsequent requests:
Firefox then opens three additional client-ports (sockets) to fetch css, favicon, fonts, javascript etc. For none of these is an OCSP response searched or sent, and they all run into an unsuccessful state within Firefox. The data transfers are, however, not abandoned, and are successful. Nevertheless Firefox keeps the failure state in internal data, and all further requests will not show any certificate data.
(*) If these initial requests were a problem, they should be easily solveable in the galley style, i.e. hire somebody to regularly beat the personnel. (fetch/wget from cron)
nginx behaviour is to not pause TLS handshakes and simply omit OCSP responses for the first TLS connection (for each configured certificate). I haven't checked how (recent) Apache versions handle this.
All of this sounds very strange and is not how I expect Firefox to behave. For example, Firefox should reuse the same TLS connection for these ressources (unless your server closes connections every time). I also don't understand why the server would stop sending stapled responses, if it just aquired one successfully.
Anway, you might want to take this to Mozillas bugtracker, as we're not the forum for misbehaving TLS servers or clients.
This is how I prime my OCSP stapling on nginx systems, yes (After each server reload, do a bunch of TLS handshakes for each certificate). This doesn't solve everything you need for stable operation with must-staple however, as your server additionally must be able to cope with weirdness that may occur on upstream OCSP servers. Many implementations are lacking here. But this is apparently not your issue.
nginx behaviour is to not pause TLS handshakes and simply omit OCSP responses for the first TLS connection
Oh! That sounds not good to me. (There are reasons why I don't use nginx)
For example, Firefox should reuse the same TLS connection for these ressources
I read elsewhere that it is supposed to open up to 4 concurrent connections. Which is what it does. I will try to clarify how these should work.
Anway, you might want to take this to Mozillas bugtracker, as we're not the forum for misbehaving TLS servers or clients.
As mentioned somewhere further up, I am already talking to Firefox people. There it is also considered weird (but was reproducable), and since this is not the first issue with stapling, the idea was already mentioned that these could be a letsencrypt problem as they apparently happen only with their certificates.
I for my part, however, am used to work with professional people who are mainly interested in how things work, and stand above blame-shifting.
So rest assured, in my viewpoint this does more and more condense into a Firefox issue.
Can you be a bit more detailed (less vague)?
Maybe it's just me but this line also seems vague:
Who has tried shifting the blame?
[and to whom?]
Maybe it's just me but this line also seems vague:
You are very welcome to ask!
So let me say this: I did understand the remark from @Nummer378
we're not the forum for misbehaving TLS servers or clients.
so that descrptions of technical (mis)behaviour in applications is not appropriate for this forum.
Since I am new here, I am not so sure about Your usual customs, so I will certainly adhere to such a hint.
Now to the contrary, You are asking me for more detailed description of what I found in the Firefox code. I am unsure how to act now.
When I remove the verification from the code, the error goes away.
Can you be a bit more detailed (less vague)?
I kept this deliberately brief because I did not want to spam this forum with pages of firefox debug messages or similar.
You can however read my full report at the firefox group, here: Firefox reports a secure connection without existing certificate | Firefox Support Forum | Mozilla Support
Who has tried shifting the blame?
It is a common behaviour whenever trying to pinpoint a problem in complex interactions of many software components.
It seems to be actually normal behaviour. From the apache documentation:
modern clients request inlined images and other data via parallel requests (usually up to four parallel requests are common)
In firefox this seems configurable in the network.http.max-persistent-connections-per-server config parameter.
I didn't understand it either, and so I started to read the TLS handshake bytes. These parallel requests, while still sending TLS extension 0x5 (status_request aka OCSP stapling), they also send TLS extension 0x29 (pre_shared_key).
From various docs I understand that this is used to resume an existing session, and this is a new feature of TLSv1.3. So here it gets to the reason why the effects are specific to TLSv1.3.
And so the bug-hunting party would end here, and the more difficult task appears: getting somebody to fix firefox. (Sadly I'm not in a position to use galley-style there, neither do I know what they charge for fixing their bugs)
Done. 1732476 - TLSv1.3 + must_staple can make the lock-icon nonclickable
Looks much like a WORN device to me, anyway (WriteOnceReadNever). Will be positively impressed if this leads to an improvement.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.