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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an in-memory cookie jar to http.Client returned by NewClient #1833

Closed
arontsang opened this issue May 8, 2024 · 3 comments
Closed

Add an in-memory cookie jar to http.Client returned by NewClient #1833

arontsang opened this issue May 8, 2024 · 3 comments
Assignees
Labels
enhancement needs triage Waiting for discussion / prioritization by team
Milestone

Comments

@arontsang
Copy link

Hello!

  • Vote on this issue by adding a 馃憤 reaction
  • If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

I am trying to use an ACME server that is behind an AWS ELB. The ELB uses cookies to ensure that an http session is routed back to the same ACME server using cookies.

Without cookies, caddy will just be connected by the ELB to random servers.

This results in the ACME server rejecting nonces that were generated by another ACME server.

Why is this needed?

Interfacing with ACME servers behind load balancers correct.

@arontsang arontsang added enhancement needs triage Waiting for discussion / prioritization by team labels May 8, 2024
@hslatman hslatman self-assigned this May 15, 2024
@hslatman
Copy link
Member

Hey @arontsang, if I understand correctly, you have multiple step-ca instances (or is it a different ACME server; maybe an ACME server hosted inside a Caddy instance) deployed behind AWS ELB, and Caddy is acting as the client of the ACME server(s)? Because if so, I don't think the fix in #1834 does what you need. That changes the client that is used to verify ACME challenges from the CA viewpoint. Usually that's just a single request, it goes out to the ACME client (in front of the AWS ELB), and it doesn't involve the nonce. So I think the issue is not on the step-ca side.

I think the fix is on the Caddy side, where you already opened the issue and I think the fix in caddyserver/certmagic#288 should work.

@arontsang
Copy link
Author

Hey @arontsang, if I understand correctly, you have multiple step-ca instances (or is it a different ACME server; maybe an ACME server hosted inside a Caddy instance) deployed behind AWS ELB, and Caddy is acting as the client of the ACME server(s)? Because if so, I don't think the fix in #1834 does what you need. That changes the client that is used to verify ACME challenges from the CA viewpoint. Usually that's just a single request, it goes out to the ACME client (in front of the AWS ELB), and it doesn't involve the nonce. So I think the issue is not on the step-ca side.

I think the fix is on the Caddy side, where you already opened the issue and I think the fix in caddyserver/certmagic#288 should work.

Yup that sounds like that is correct. Thanks you.

@arontsang
Copy link
Author

Closing

@arontsang arontsang closed this as not planned Won't fix, can't repro, duplicate, stale May 15, 2024
@hslatman hslatman added this to the v0.26.2 milestone May 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement needs triage Waiting for discussion / prioritization by team
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants