Hi,
I have an ATS instance that has OCSP stapling enabled. The logs
dutifully show:
[Apr 12 20:28:11.077] Server {0x2b0d22181700} NOTE: Success to refresh
OCSP response for 1 certificate.
[Apr 12 21:29:11.138] Server {0x2b0d22181700} NOTE: Success to refresh
OCSP response for 1 c
Leif Hedstrom wrote:
> Which version of ATS is this?
This is 5.3.0; haven't tried/checked other versions.
-Jan
Leif Hedstrom wrote:
> Ah so, 5.3.0 is not a supported version, and 6.2 is going to be
> EOLifed in a few months. A lot of things have changed since 5.x,
> including OCSP stuff (it now supports proxying the OCSP requests for
> example).
Fair enough. I'll see if using 7.x makes a difference.
T
Leif Hedstrom wrote:
> You think it?s a serious burden to send an email to
> e.g. users@ or dev@ and ask for an invite?
For people who are part of the community already, this
isn't an issue, but I do believe that this raises the
barrier to entry for newcomers. As a data point, _I_
wouldn't bot
Hi,
I'm looking for information about in how far ATS supports Certificate
Transparency and the Expect-CT header.
My understanding is that a web server can provide the Signed Certificate
Timestamps (SCTs) -- if they are not embedded in the certificate via an
x509 extension by the CA -- either via
Dave Thompson wrote:
> A quick read through the 7.1.1 ATS code for OCSP handling, looks like we're
> using the OpenSSL API to handle interaction with CA, and then passing the
> response into our OpenSSL context for stapling in handshake. So, I
> believe the SCT is in the CA's response, though
