tls

It seems Caddy does not support wildcards/ expression matching in the reverse proxy's header_up.

For example this does not remove any headers:

header_up -X-SHIBBOLETH-*

This works as expected, but is limited in its use:

header_up -X-SHIBBOLETH-LOGIN

It'd be great if Caddy would support wildcards/ expression matching in the reverse proxy's header_up/ header_down.

I'm using a /etc/cron.daily/ file that does:

#!/bin/sh

BITS=4096
GENERATOR=-2

openssl dhparam -out /etc/pki/tls/misc/dhparam.pem.new \
		$GENERATOR $BITS > /dev/null \
	&& mv -f /etc/pki/tls/misc/dhparam.pem.new /etc/pki/tls/misc/dhparam \
	&& apachectl restart

to generate daily dhparam files which I then use in ssl.conf as:

SSLOpenSSLConfCmd DHParameters /e

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)

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

jetstack/cert-manager#3607 implies that certificates are not re-issued if key usages change. This behaviour should be documented and tested with an appropriate conformance test.

https://cert-manager.io/docs/usage/certificate/ should be updated as well

Additional context
https://github.com/jets

There's little information about what keys and values are in the output, what it means and how they are related to the screen output. In general that needs to be added. (special topics see #1675, #1674)

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.

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

Since 3.0, all fields of mbedtls_ssl_ticket_key and mbedtls_ssl_ticket_context are now private. It turns out some applications where accessing them (originally reported in #5331):

lighttpd allows synchronization of session tickets
across multiple servers, and so writes into mbedtls_ssl_ticket_context to
manage mbedtls_ssl_ticket_context.
lighttpd `mod_mbedtls_session_ticket_key_ch