tls

It would be a nice addition to integrate Minimal windows service stub in Caddy (built for Windows).

At the moment, it is necessary to use for example NSSM to install Caddy as a service on Windows.

See how it becomes much more natural to [install the service and remove it in the case of another project (Gitea) with the Windows tools](https:

OpenSSL 1.1.1h introduces a behavior change wherein one can no longer set an EC_KEY's private_key to NULL.

This behavior changes in 6a01f6f4b41d045e2a3abcb10163633d769db76a. Based on the original PR (openssl/openssl#11127), it appears that this is hardening backported from 3.0.0 that unintentionally introduced a regression.

From https://github.com/openssl/openssl/comm

Is your feature request related to a problem? Please describe.

I've experienced intermittent issues with the k8s api-server reaching the cert-manager-webhook, or so I think. I wanted to understand and verify if the webhook received the requests or not, and sometimes it seems to work out.

The issue is that there is no logs for me to see this from the webhook pod, even with --v=6 set.

Right now in different places in the SE codebase there are references to /opt and then as well to /usr.

All SE code should reference one place only. Could someone please create a PR that fixes this.

This PR should also take PR #454 into consideration (no conflicts)

Which version are you referring to
3.1dev

We list not all RFCs in ~/doc/ which we refer to in testssl.sh.

List used RFCs: grep RFC -w ./testssl.sh | grep -v TLS_CIPHER | grep RFC | sed 's/^.*RFC/RFC/' | sort -u
List RFCs referred to: grep -w RFC doc/testssl.1

The recommendation is to set Cache-Control: private, no-store on any endpoint with sensitive information. Because while you can protect the traffic with TLS, you also need to keep sensitive information out of a client's (unencrypted) HTTP cache. I'm not sure how relevant this is to the API context of step-ca though—I've never seen an HTTP client library that caches content. But I guess the poi

Problem:

A common pattern is:

GUARD(s2n_stuffer_skip_write(stuffer, bytes_to_write));
uint8_t* ptr = suffer->blob.data + stuffer->write_cursor - bytes_to_write;

which could be simplified.

Solution:

*ptr could be an *out parameter to s2n_stuffer_skip_write

• Does this change what S2N sends over the wire? No.
• Does this change any public APIs? No.