Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Since 1.0.0 tls certificate selection does not work as expected #2588

Closed
lukenowak opened this issue Apr 26, 2019 · 19 comments

Comments

@lukenowak
Copy link
Contributor

commented Apr 26, 2019

1. Which version of Caddy are you using (caddy -version)?

v1.0.0 compiled from source

2. What are you trying to do?

I am serving sites using tls directive, that for each site there is separate certificate.

Certificates are generated like:

openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout 02.pem -out 02.pem -subj '/CN=*.example.com/O=02/'
openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout 01.pem -out 01.pem -subj '/CN=*.example.com/O=01/'

3. What is your Caddyfile?

https://01.example.com:6443 {
  bind 127.0.0.1
  tls 01.pem 01.pem
}  
https://02.example.com:6443 {
  bind 127.0.0.1
  tls 02.pem 02.pem
}

4. How did you run Caddy (give the full command and describe the execution environment)?

./caddy -log stdout -pidfile caddy.pid

5. Please paste any relevant HTTP request(s) here.

curl -v -o /dev/null -k --resolve 01.example.com:6443:127.0.0.1 https://01.example.com:6443 2>&1 | grep subject
*       subject: O=01,CN=*.example.com
curl -v -o /dev/null -k --resolve 02.example.com:6443:127.0.0.1 https://02.example.com:6443 2>&1 | grep subject
*       subject: O=01,CN=*.example.com

6. What did you expect to see?

curl -v -o /dev/null -k --resolve 01.example.com:6443:127.0.0.1 https://01.example.com:6443 2>&1 | grep subject
*       subject: O=01,CN=*.example.com
curl -v -o /dev/null -k --resolve 02.example.com:6443:127.0.0.1 https://02.example.com:6443 2>&1 | grep subject
*       subject: O=02,CN=*.example.com

7. What did you see instead (give full error messages and/or log)?

curl -v -o /dev/null -k --resolve 01.example.com:6443:127.0.0.1 https://01.example.com:6443 2>&1 | grep subject
*       subject: O=01,CN=*.example.com
curl -v -o /dev/null -k --resolve 02.example.com:6443:127.0.0.1 https://02.example.com:6443 2>&1 | grep subject
*       subject: O=01,CN=*.example.com

Caddy log on startup:

2019/04/26 09:05:24 [INFO][cache:0xc000032280] Started certificate maintenance routine
2019/04/26 09:05:24 [WARNING] Stapling OCSP: no OCSP stapling for [*.example.com]: no OCSP server specified in certificate
2019/04/26 09:05:24 [INFO] Successfully loaded TLS assets from 01.pem and 01.pem
2019/04/26 09:05:24 [WARNING] Stapling OCSP: no OCSP stapling for [*.example.com]: no OCSP server specified in certificate
2019/04/26 09:05:24 [INFO] Successfully loaded TLS assets from 02.pem and 02.pem
Activating privacy features... done.

Serving HTTPS on port 6443
https://01.example.com:6443 (only accessible on this machine)
https://02.example.com:6443 (only accessible on this machine)

2019/04/26 09:05:24 [INFO] Serving https://01.example.com:6443 (only accessible on this machine)
2019/04/26 09:05:24 [INFO] Serving https://02.example.com:6443 (only accessible on this machine)
2019/04/26 09:05:35 [WARNING] Sending telemetry (attempt 1): telemetry server returned status code 403 - backing off and retrying
2019/04/26 09:05:45 [NOTICE] Sending telemetry: we were too early; waiting 1h1m16.266725991s before trying again

8. Why is this a bug, and how do you think this should be fixed?

As each site has different certificate, I would expect it to be served with different certificates, it was working pre 1.x.x

9. What are you doing to work around the problem in the meantime?

Downgrade to before 1.0.0-beta1, which does not include certmagic rewrite

10. Please link to any related issues, pull requests, and/or discussion.

I think this can be related to #2571

@lukenowak

This comment has been minimized.

Copy link
Contributor Author

commented Apr 26, 2019

I just confirmed that on https://github.com/mholt/caddy/releases/tag/v0.11.5 it works as expected (thus we apply this workaround for now, reverting to v0.11.5).

@mholt

This comment has been minimized.

Copy link
Member

commented Apr 26, 2019

Why do you have two different certificates for serving *.example.com? The names overlap so it's ambiguous which one would be chosen.

@lukenowak

This comment has been minimized.

Copy link
Contributor Author

commented Apr 26, 2019

Why do you have two different certificates for serving *.example.com? The names overlap so it's ambiguous which one would be chosen.

Indeed, but I expect that selecting certificate with tls cert.pem cert.pem would enforce using exact certificate, and that no more automatic handling happens. Something else would be providing directory with certificates, then I'd let Caddy to choose the best matching one.

In our environment we host various sites, which by using SAN DNS can have overlapping certificates, but users want exact selection.

NexediGitlab pushed a commit to SlapOS/slapos that referenced this issue Apr 26, 2019
This reverts commit 6d2019b, as new caddy
has issues with tls certificate configuration:
caddyserver/caddy#2588

About nxd-v0.11.5-4-g9d3151db:

 * not released yet functionality for regular expression cookie rewriting
   is available: caddyserver/caddy#2144

 * not released yet functionality for ca_certifices in proxy:
   caddyserver/caddy#2380

 * support for builtin log rotation disabling
@mholt

This comment has been minimized.

Copy link
Member

commented Apr 28, 2019

I see. So, yes, this is a weird edge case... here is what happened.

I expect that selecting certificate with tls cert.pem cert.pem would enforce using exact certificate, and that no more automatic handling happens.

When you specify a certificate manually like this, it is loaded into memory, into the "certificate cache" we call it. Certificates loaded manually aren't handled automatically, as you suggest. But all certificates -- both manual and managed -- are loaded into the same cache. The only difference is a little flag that indicates whether they are manually or automatically managed. Certificates are simply placed there in the cache (regardless of where they came from) and indexed by their SANs for recall upon a TLS handshake where the SNI matches one of those SANs.

What happened is that a recent refactoring of CertMagic actually fixed a bug where certificate configurations were static, even if the underlying configuration changed from the time that it was loaded or obtained and the time that it was reloaded or renewed (about 60 days, or longer). This was due to certificate configs being designed to be short-lived, not long-lived, yet attaching them to certificates (which are long-lived) made them "leak" in memory in the sense that even if the config associated with a certificate was changed, it wouldn't be replaced on the certificate.

That is all fixed now, but I suppose the reason this is affecting you is because we removed the buggy mapping between configs and certificates, but in doing so we just use the first matching certificate by SAN, since there's no config mapping to require that a specific certificate for a given SAN is used; rather it just uses the first one that matches the SAN.

I will see about improving on this in Caddy 1 for a fix, as well as ensuring that Caddy 2 has this capability as well.

@mholt mholt self-assigned this Apr 28, 2019
@mholt mholt added this to the 2.0 milestone May 9, 2019
mholt added a commit to mholt/certmagic that referenced this issue May 23, 2019
@mholt

This comment has been minimized.

Copy link
Member

commented May 23, 2019

@lukenowak I pushed a commit to upstream dependency CertMagic to make it possible to customize certificate selection logic.

Am I correct in understanding, then, that given a list of certificates that match the ClientHello, by inspecting each certificate and comparing it to the ClientHello, it should be easy to decide which certificate to use?

i.e. it seems in your case that you simply need a map of ServerName (in the ClientHello) to Subject Organization (in the x509 cert). Is that right?

@lukenowak

This comment has been minimized.

Copy link
Contributor Author

commented May 29, 2019

i.e. it seems in your case that you simply need a map of ServerName (in the ClientHello) to Subject Organization (in the x509 cert). Is that right?

I used Subject Organisation only for demonstration purpose, as it was easy to be extracted by curl. I see now that it did not explain my use case (edge one, I can tell).

What I really want is that is that while I use tls certificate on a given site it will use that exactly selected certificate for this site.

I think that your solution happens later. I did not dig it more, but AFAIK the explicit information from Caddyfile is not used while negotiating the certificates, and it was like this before.

So extending my usage the certiifcate generate would be like:

openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout 01.pem -out 01.pem -subj '/CN=*.example.com/'
openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout 02.pem -out 02.pem -subj '/CN=*.example.com/'

(So no subject difference)

But while accessing 01.example.com I would be able to read 01 certificate and with 02.example.com it would return 02 certificate.

I got the feeling that previous versions were support it correctly.

Background: We host sites for multiple users in one caddy process. Each user in our context can add controlled snippet to caddy file and select it's own certificate. Thus it is possible, that they will use same certificates (eg. supporting wildcards in altName DNS or IP), but they would expect to have them served on thier own different website (like the *.example.com wildcard for 01.example.com and 02.example.com)

@mholt

This comment has been minimized.

Copy link
Member

commented May 29, 2019

@lukenowak Okay, so here's what I need from you in order to fix this (either in Caddy 1 or 2, will see depending on what you need): given a TLS ClientHelloInfo and list of loaded certificates which match the ServerName value, what is the exact logic you need to choose the right certificate?

Keep in mind that if there is an exact match, foo.example.com for example, that will always match over *.example.com. Only when there are multiple foo.example.com certificates or no foo.example.com and only multiple *.example.com certificates would you encounter this situation...

@lukenowak

This comment has been minimized.

Copy link
Contributor Author

commented May 31, 2019

given a TLS ClientHelloInfo and list of loaded certificates which match the ServerName value, what is the exact logic you need to choose the right certificate?

The logic I want to have -- but without knowing if possible with loaded list of certificates in ClientHelloInfo -- is:

openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout 02.pem -out 02.pem -subj '/CN=*.example.com/'
openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout 01.pem -out 01.pem -subj '/CN=*.example.com/'

cat Caddyfile
https://01.example.com:6443 {
  bind 127.0.0.1
  tls 01.pem 01.pem
}  
https://02.example.com:6443 {
  bind 127.0.0.1
  tls 02.pem 02.pem
}

curl -v -o /dev/null -k --resolve 01.example.com:6443:127.0.0.1 https://01.example.com:6443
# I see that certificate 01.pem is used
curl -v -o /dev/null -k --resolve 02.example.com:6443:127.0.0.1 https://02.example.com:6443
# I see that certificate 02.pem is used

# I can differentiate the received above here by using not valid before/after dates

It worked this way < 1.0.0.

Is it possible > 1.0.0? Is my request to unusual/hard with Go library/maybe I am just doing things outside the spec?

It comes from me seeing tls switch, which select exact certificate for given site. I am ok with Caddy not using "incorrect certificate" (like CN/altSubjectName does not match site name, etc).

I am ok with load (which I do not use, as I want to have precise selection of certificates per host) to use any smart logic to select certificates. I expect tls <cert> <cert> to be not smart at all in this case.

@mholt

This comment has been minimized.

Copy link
Member

commented Jun 14, 2019

I think what we will have to do is make it possible to give each certificate an ID in the config when it is loaded, and then you can require a TLS handshake to use a certificate with that ID.

@lukenowak

This comment has been minimized.

Copy link
Contributor Author

commented Jun 20, 2019

Thanks!

I think what we will have to do is make it possible to give each certificate an ID in the config when it is loaded, and then you can require a TLS handshake to use a certificate with that ID.

Does it mean, that some additional steps in configuration or in the client would be required to use selected certificate by tls, or the ID is going to be internal thing for Caddy to select the certificate?

@mholt

This comment has been minimized.

Copy link
Member

commented Jun 20, 2019

Does it mean, that some additional steps in configuration or in the client would be required to use selected certificate by tls, or the ID is going to be internal thing for Caddy to select the certificate?

I think with the Caddyfile, the mapping of loaded certificate to some auto-generated ID will be automatic. Apparently we just need a way to associate which certificate was loaded specifically for which site, independent of the name(s) on the certificate, or any other fields of the certificate, for that matter. That's why we need an external ID to associate with.

mholt added a commit to mholt/certmagic that referenced this issue Jun 24, 2019
This allows for user-loaded certificates to be associated with arbitrary
values such as user-provided IDs or categories. This can be useful if
multiple certificates satisfy a ClientHello but if a specific one still
needs to be chosen. See for example:
caddyserver/caddy#2588

This is a breaking API change since we need to expose a tags parameter
to the caching functions, but we're not 1.0 yet so we will try this
API change and see how it goes.
@mholt

This comment has been minimized.

Copy link
Member

commented Jun 24, 2019

@lukenowak I've pushed mholt/certmagic@6a42ef9 which lays the foundation for this. Basically, certificates that are manually loaded can be associated with tags, which can be anything, like an ID. The reason this is useful is because certificates don't inherently have IDs that provide continuity between renewals and stuff. Even X509 serial numbers aren't consistent or reliable. But you can say "this certificate, which we generated for this customer, has this ID" - no matter the actual contents of the certificate or its renewals.

Anyway, it looks something like this in Caddy 2 config:

{
	"certificate": "cert.pem",
	"key": "key.pem",
	"tags": ["customer1"]
}

And then you would define a certificate selection policy for that particular host name to map to that customer's certificate:

{
	"match": {"host": ["example.com"]},
	"certificate_selection": {
		"policy": "enterprise",
		"tag": "customer1"
	}
}

(These certificate selection capabilities are available in the upcoming Caddy Enterprise.)

I've been careful to optimize the certificate selection for the use case where there may be thousands of different hostnames you need to match.

I think we can get this to work (mostly) implicitly with the Caddyfile adapter, I'll just need more time to figure that out. I'm not sure yet how/if this would work in Caddy 1, but it definitely will in Caddy Enterprise.

@lukenowak

This comment has been minimized.

Copy link
Contributor Author

commented Jun 25, 2019

I think we can get this to work (mostly) implicitly with the Caddyfile adapter, I'll just need more time to figure that out. I'm not sure yet how/if this would work in Caddy 1, but it definitely will in Caddy Enterprise.

Ok, thank you, that gives me good info.

As it means that it's unsure if it'd land in Caddy 1, I will then accept current Caddy 1 state. At least we know the situation and the limits, and we will know that we can obtain this functionality with Caddy 2 or Caddy Enterprise.

@mholt

This comment has been minimized.

Copy link
Member

commented Jun 25, 2019

Sounds good. Even though I could probably figure out a way to work this into Caddy 1, I am not sure it will be worth the time -- however, if it turns out that accepting the current Caddy 1 state is not feasible on your end, reach out to me via email and we can work something out.

But yeah this is working in Caddy 2 already. Let me know if you guys want to test an early dev build of it, and give us your feedback!

NexediGitlab pushed a commit to SlapOS/slapos that referenced this issue Jun 26, 2019
This also means that caddy source is fetched directly from upstream, as all
required fixes has been incorporated into the upstream.

Drop direct usage of gowork for now, in order to have caddy built using go
module, support for gowork with go modules might come later.

Follow new way of certificate managament in Caddy 1 as noted
caddyserver/caddy#2588 (comment)
@mholt

This comment has been minimized.

Copy link
Member

commented Jul 5, 2019

@lukenowak Caddy 2 is now ready for you to try, with the necessary design changes to accommodate your use case. Here's the documentation: https://github.com/caddyserver/caddy/wiki/v2:-Documentation - specifically you'll want this module. Just add tags to your certificates when you load them via the config.

Advanced certificate selection (which you need) is available in the Enterprise builds. Let me know the preferred platforms and I will send you binaries you can test out!

And feel free to reach out here, or on our forums, or via email, and I can also walk you through the setup process if you need. Or we'll invite you to our Slack if you prefer that. It just depends how involved you want to be. 👍

@lukenowak

This comment has been minimized.

Copy link
Contributor Author

commented Jul 15, 2019

Hello,

Even though I could probably figure out a way to work this into Caddy 1, I am not sure it will be worth the time (...)

Maybe I found a scenario worth the time fixing it in Caddy 1.

Seems there is a bug with modern certificate selection in Caddy-1 which selects expired certificates matching the CN of the host. Fixing it is good thing per se, but I think such problems won't occur if the precise selection of certificates defined in each vhost entry would be in place.

Please see my Caddyfile:

https://oink.example.com:8989/ {
  bind 127.0.0.1
  tls expired.pem expired.pem
}

https://example.com:8989/ {
  bind 127.0.0.1
  tls active.pem active.pem
}

Using curl to check certificate shows that example.com is served with definitely wrong certificate:

curl -vk --resolve example.com:8989:127.0.0.1 https://example.com:8989 2>&1 | grep expire
*  expire date: Dec 23 23:00:01 2008 GMT

In our configuration we use a lot of https:// blocks with a lot of certificates, and we accept that expired certificate can affect one site, but no others.

active.pem is Jul 15 13:16:58 2019 GMT - Jul 1 13:16:58 2119 GMT:

-----BEGIN PRIVATE KEY-----
MIIEpAIBADANBgkqhkiG9w0BAQEFAASCBI4wggSKAgEAAoH9AskEw0kZR/hC6fvY
VXZ2ouQDlE8GeQHAqVluen3b+rs1spxdoOrbasNFTgBDVaQ3z/41UB0dgLhLCph2
ziiXi8xRe+QjwAMXmzY6NNcD1Hm92eYWhVcx+hhAM7aK0RxUtt3nAY8AtF6T/eU4
JDHMGzupUH+P+kPI07tf6EtVNlty/vU+gYOm5yLqV2zEZRVerUSvv8o0i4Ij1hmT
AJt+ZVCIu+e6XEEa+K5HHMDUgUiSzuovBVw0y0z0Ja8PT/hNnPDz19WEsBU1DZYv
hfYsHw7pT8WuLEmWakwMuJ/tFOg//OB81e25G+zCfqKPMOCIx+Lc1tEAxbaWiIXj
ewIDAQABAoH9Al05Ir6QrAtqWQyCFAELMLcU5rWxi9NWAym7YlQk/o4cRXD+9JGG
D/iSgmQsw6wyB+YCwO8F1PYaFHNYHSRNhse2vs/nHJxDVGdSPvnn8VopMaVhpmte
K6icDok7CcbfjZ2L8UG+WlwRiKkh3285jkA1NvQgdVFGTZs2DIqtVjDNl1F5aKM3
h+dglyPvv/uLNT77dlx2fxU/ZY3XHK+D+xaQ26jQNICfK63P/7qGFEHzbWr524TZ
RMSjHtU+jDmBRR3gcBPw8RjlQ0yUdfBIAr5xcNBjQIFq3kUbOkG9l4HW+PLnKbTS
Uhsqq1CaKj+pVz6zg3sroEtKG3+MEQJ/AcbUAW7tuhSnM/Src+rJp9FTyAS+lw7T
Yl/7/quZtVRPgMmNtlE8Fn/xho/X9/29OE1LolAgFFh6h2lGoKtm1qWG5xQ3O6p0
cffv5cMeFl+pSGrUpDA8cQe5NwE88SY8PxIY/iocxubfsG+rCDNdKV6LdZ0p8pf1
iMw0H5zJAwJ/AZFSjnm8M3hLPpK3jsnjtjImQT7tJQhIZlzzvVJjCNLQ6Nm93a1N
DIahsnL7ZyWcEwrX2Pp/3Grwuwro33j0YDJW8gW96/o9202ATGpAWZxBJ7mAdt/M
EB9r7iOstf9XHqtIhCxTkPicYDPW4bjhDNLjdYN3ge1m1kLRTZvmKQJ+AgbHytq8
TYNBNAHfjlg/qysYZQ0EV0iR06OnytPwfuOryzoaado+r2tAEjwAGt1Q9uczXfAG
py5ElC+AX8MhibNELE7isSu7pkMnXusvZlW2wOMZqC1cw5ALsrG20VjLXyVFXKKs
MDMm8hhs/O2ZVZaBe6XIMu0hIufIjEZJAn4WMrPQxfku2TKf2Olb/21vfrAzM9jN
iXun/o9lRDcTuhx3FspxMIbV15HQTFmbOfPPsLq+uF3PyHsAEntx7Ep53ldKvAOW
dt9vfP49DkwmmXACEboBjP8DTewBKydx9TasELnG3eRx6+xiUatwl3onHA++8thL
8lk9nuglDGkCfhTAwgscpvHwabon3XkZ5IDUdmCzq7H8+bhuAo43Ow8SOZyzh7Hj
y5g9VdfPKw7CHK/pVd2JlKe5kTmd5Hoar8hBUMrx1KTJc1XacdmEE5g+4k8GHNZ0
srCDCHwNEfCoAP57759usOKYCMuY8M5/7nnO4IoRddnQAu/DVwuqSw==
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIC+zCCAeegAwIBAgIJAMPrw8RdJh2WMA0GCSqGSIb3DQEBCwUAMBYxFDASBgNV
BAMMC2V4YW1wbGUuY29tMCAXDTE5MDcxNTEzMTY1OFoYDzIxMTkwNzAxMTMxNjU4
WjAWMRQwEgYDVQQDDAtleGFtcGxlLmNvbTCCAR0wDQYJKoZIhvcNAQEBBQADggEK
ADCCAQUCgf0CyQTDSRlH+ELp+9hVdnai5AOUTwZ5AcCpWW56fdv6uzWynF2g6ttq
w0VOAENVpDfP/jVQHR2AuEsKmHbOKJeLzFF75CPAAxebNjo01wPUeb3Z5haFVzH6
GEAztorRHFS23ecBjwC0XpP95TgkMcwbO6lQf4/6Q8jTu1/oS1U2W3L+9T6Bg6bn
IupXbMRlFV6tRK+/yjSLgiPWGZMAm35lUIi757pcQRr4rkccwNSBSJLO6i8FXDTL
TPQlrw9P+E2c8PPX1YSwFTUNli+F9iwfDulPxa4sSZZqTAy4n+0U6D/84HzV7bkb
7MJ+oo8w4IjH4tzW0QDFtpaIheN7AgMBAAGjUzBRMB0GA1UdDgQWBBSg6j2/yqSw
Uh8qbW9mHlzGALCpxTAfBgNVHSMEGDAWgBSg6j2/yqSwUh8qbW9mHlzGALCpxTAP
BgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBCwUAA4H+AAJrqghK9nMlROs/ZM4i
UaAq653+dUCGjIxl98s8toUtTgKrCsK3nTtdobaY4snFni7G8752PqVugDwh0ML4
z2++JnDD4v6zMN7SGkaeu6NpfKYgpKGm+ivCtPSF6zETf8ZzEqe2rpQ/8gpJuWhl
QWqGjPvIAKIvnzPOASMiH3+5kJnzQp50rFcZ9rYr0rF+VMbjtizZvEX2sJRgDATJ
NRlYKw5bvB56wAC/7iwj1mG8E7BwCmbrJ0gNUqjDoe1+vW3jZ7iWncOzBQLEnKA7
l9jCXi1IqWCz3WvZimnbVxNFW4bHuj4x2azyNyWF0uaXGrf4gv1yyRe4HQu1jFE=
-----END CERTIFICATE-----

expired.pem is Dec 13 23:00:01 2008 GMT - Dec 23 23:00:01 2008 GMT:

-----BEGIN PRIVATE KEY-----
MIIEpgIBADANBgkqhkiG9w0BAQEFAASCBJAwggSMAgEAAoH9A57aypR3dBPdGO0L
us2XCiO3m6+Qg2vh1iNlBAI1MVI6wlkMDzHe1kFb1oiNUEbhKIupCEanqMbH23V6
O1VfqiIxyUhQcLa50iZXPsvu57D0RrYY5YvGozRYK4HPs02UcC66dpah5tUU2cJe
g2lwOCKQk6ifO6owiquOyzfjz0AeibN/HSJnRznxOkxl9GH+UajoAORVOsrNLYvV
jBa4iKaK7jO/5gDV7MXJOZceMTMeK0zGc/WquHxTagXJJnjWjGOLmtGTF7i5S8oe
CZYznO7oycbogzt81hyqtBtDM+uRVDVqxp3juOKcbXbfK+KllS89eVYIeMg0/uCg
VwIDAQABAoH9AJi9FYVB6i8b0G+/7xjSOymHqHBWMFIm9VL/4pk6itYyOLTT9+0P
+97pc4EtSH1lvXjGckayem3HobLKYdy/1xmrerAgEXMLTEZlOkQBKs1OdBiuIaXX
Ji4KGaFayQGP5KzOrZxFMfULapdNW/qUM6v+h1bSZtK1DSUYcwTS1UPe82VMOW/n
1hgOgRV7yOnNB4VcO2mgssPnyf45z7FuMpvq0EMVlfLq83EI/qZOP+gFMPR7NaXe
s4eBaMmh6c3cE/p9a9mLOlB5OFn5P4XaEbKwz+y5NlHW5QrImVMxRchTbHDKaj+f
/lS1FqH0CDoxB1fR8WNuKNs8uRqHgQJ/AfsIQDjvpHk7fqSYH82muQn6ffTWfyUG
k8NxA1lwVCYwapPLikV40Rk7E3ftrcD/GVj9kxxBwpTEVjDBh3MnbVtmOXJXbS1H
GLY+wFS/KknO9RQNtbs2Xq8Pq9q0aZCfzYQ/7EMvv+tPy0bWOChMqxVh+X13RwjV
y00WU2CSxQJ/AdP3xieC/FsDcJkIGsejlXmgzxh7rlxpqlU8vHLHfvlN/rv1VfKw
rk2asrb/ND59wr/WbRqcubJWbAJBeaKvrJrViuq5JeQ5Uita22gPALHOq1hUwi8h
MY+GyqUBMTsfNH48DfY9a1exLficmaTKZGZD83kLYfX6oqORe4qoawJ/ATNpuj6L
FYanis5SqZ2vgytIo8uprWcOiNKLl8NHds28tzGqy8f5S5XnmpMxGRMV2BF7lREh
0c8PB08CV5R7CDPNU/E+jqRQIeyFOWloikQ75Z3l/hRnD5tGfiTZE9Qq/5k6hI3r
yonqVE47ncrZSTVqtLDce8YgkeXILn80HQJ+bKSWdW/chIi86FpQVU7uEem6irWU
GlJRwC40lfUozlpELIDdrlVEcjHbEc8X4vYxc3YlqEsAdZ3Iv5FR2uosCVpQQQQw
/tYr9HLIg1UQVTdk4kHzPxvWtLqXa01mj5JEDpaEq0lBFX/F63T32qE+Q9u8t7pj
yMaiYZUR+HP3An8BOjHu5MOJr5Nhe/8LA1Tn1QNVJ4ZU7mxzXjLMASaWbo5YE9ff
8M7OC5TmTYMirlGXHY0nVOFuekDCGqVBZhctdtEki03GYpjCrQvYHWMoDSQ8ZC4G
4qlbGitZ4LUEgNiMpPnlfO3ssCa6eHOJtOMMJCxG1NgWaLD4gjrNDXrn
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIC+TCCAeWgAwIBAgIJAN/mTuvven1RMA0GCSqGSIb3DQEBCwUAMBYxFDASBgNV
BAMMC2V4YW1wbGUuY29tMB4XDTA4MTIxMzIzMDAwMVoXDTA4MTIyMzIzMDAwMVow
FjEUMBIGA1UEAwwLZXhhbXBsZS5jb20wggEdMA0GCSqGSIb3DQEBAQUAA4IBCgAw
ggEFAoH9A57aypR3dBPdGO0Lus2XCiO3m6+Qg2vh1iNlBAI1MVI6wlkMDzHe1kFb
1oiNUEbhKIupCEanqMbH23V6O1VfqiIxyUhQcLa50iZXPsvu57D0RrYY5YvGozRY
K4HPs02UcC66dpah5tUU2cJeg2lwOCKQk6ifO6owiquOyzfjz0AeibN/HSJnRznx
Okxl9GH+UajoAORVOsrNLYvVjBa4iKaK7jO/5gDV7MXJOZceMTMeK0zGc/WquHxT
agXJJnjWjGOLmtGTF7i5S8oeCZYznO7oycbogzt81hyqtBtDM+uRVDVqxp3juOKc
bXbfK+KllS89eVYIeMg0/uCgVwIDAQABo1MwUTAdBgNVHQ4EFgQU7ZaSI1/8IogP
tcBrCZoljp/SSnUwHwYDVR0jBBgwFoAU7ZaSI1/8IogPtcBrCZoljp/SSnUwDwYD
VR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQsFAAOB/gAAO3EcseZ2Mtq29yCIzSs5
42XyplyoREKYCI1/Fs7tT3qBiSxscnVNAUQiDCzpsYlI4qx8pVzGcNsc8ZGqKPKR
ix/j7AVxEbvpeLxCZQPb59TptEsx7219BCxhD5hDcE+Nisr9PGeC2se3l4+ddIoT
SVkh2OMh8mQzpl4cRgvMtqajX7hEJIVPkXeDHcho6gyevCJGN8s6vaomiSsHeLPQ
0g6paF5X26+mftjvvmvDfdhoO9T37YTijexoFy0wWpLcJNiWkIQwxoY41K+Mx+jg
KUeZGkBhEOTGF49OI0tbGGpRD9Ohp66fola4YG+HJg8+WEDYAKvYAIdOdSl9
-----END CERTIFICATE-----
mholt added a commit to mholt/certmagic that referenced this issue Jul 15, 2019
@mholt

This comment has been minimized.

Copy link
Member

commented Jul 15, 2019

I echo your comment that giving Caddy expired certs is a bad idea. ;)

I've pushed a quick and reasonable fix for that case to mholt/certmagic@8ae95e4 -- CertMagic will simply choose the first matching unexpired certificate, which Caddy 1 can use on the next patch release. Caddy 2 will benefit from this too, but in Caddy 2 you can specify your own selection logic as I've described, so it won't matter I think.

Have you had a chance to try Caddy 2? Doing so sooner rather than later will ensure it can meet your needs in the best way possible.

@lukenowak

This comment has been minimized.

Copy link
Contributor Author

commented Jul 16, 2019

I've pushed a quick and reasonable fix for that case to mholt/certmagic@8ae95e4 -- CertMagic will simply choose the first matching unexpired certificate

Thank you :)

Have you had a chance to try Caddy 2? Doing so sooner rather than later will ensure it can meet your needs in the best way possible.

Not yet, I will do it, as this will give us answers if all works as expected :)

NexediGitlab pushed a commit to SlapOS/slapos that referenced this issue Jul 18, 2019
This also means that caddy source is fetched directly from upstream, as all
required fixes has been incorporated into the upstream.

Drop direct usage of gowork for now, in order to have caddy built using go
module, support for gowork with go modules might come later.

Follow new way of certificate managament in Caddy 1 as noted
caddyserver/caddy#2588 (comment)
@mholt

This comment has been minimized.

Copy link
Member

commented Sep 25, 2019

This should be resolved now between those changes in CertMagic and the implementation in Caddy 2. Thanks!

@mholt mholt closed this Sep 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.