Incorrect protocol (HTTPS) in generated links when running with HTTP

[amalchuk]

The application/library currently generates URLs with "https" as the protocol. This is problematic because the application can be run with an HTTP server. The hardcoded "https" prefix in certain parts of the code results in incorrect URLs being generated, which can lead to issues with functionality.

Steps to Reproduce:

1. Start the application/library with an HTTP server.
2. Observe the generated links (e.g., in logs, UI, or responses).
3. Notice that the links are prefixed with "https" instead of "http."

Expected Behavior:

The application/library should dynamically determine the correct protocol (HTTP or HTTPS) based on the server configuration and generate links accordingly.

Impact:

Incorrect URLs generated by the application/library. This could lead to broken links, incorrect redirection, and other unexpected behavior.

Possible Solution:

Refactor the code to avoid hardcoding the protocol and instead dynamically determine the protocol based on the server configuration. (e.g., read the protocol from a http.Request variable.)

Specific Locations of the Issue:

The hardcoded "https" prefix can be found in the following files:

• https://github.com/smallstep/certificates/blob/v0.28.4/acme/linker.go#L160
• https://github.com/smallstep/certificates/blob/v0.28.4/acme/linker.go#L222
• https://github.com/smallstep/certificates/blob/v0.28.4/acme/api/middleware.go#L195

Additional Context:

This issue affects both the standalone application and when the library is used as a dependency in other Go projects. I have created a proof-of-concept application that utilizes the 'acme' module from this library. The hardcoded 'https' protocol is preventing me from properly testing and deploying my application in an HTTP-only environment.

[hslatman]

Hey @amalchuk, thank you for opening the issue

Returning http or https based on the server configuration or request is not a satisfactory solution, imo, because ACME generally must only be served over HTTPS. This is described in the protocol overview section: https://datatracker.ietf.org/doc/html/rfc8555/#section-4 and section 6.1: https://datatracker.ietf.org/doc/html/rfc8555/#section-6.1. That is also the reason ACME endpoints are never served over HTTP in step-ca. We limit which endpoints are available on HTTP by explicitly including only a subset of all endpoints available. This issue thus does not affect the standalone application; it is expected behavior.

For very specific cases I can see serving ACME over HTTP somewhat useful, but if we were to support that, it would have to be made very explicit that it's not a standard practice. Can you tell something more about your use case? I'm primarily curious about your statement "my application in an HTTP-only environment": if it's an HTTP-only environment, what do you need ACME for? Do you actually mean you would like to start with HTTP-only at first, then "upgrade" to HTTPS?

[amalchuk]

You are absolutely correct @hslatman, and I apologize for the initial misunderstanding.

The core point is that ACME should operate over HTTPS. However, I can deploy the application in front of an HTTP load balancer (like Nginx, HAProxy, or Traefik) and configure SSL termination there. The application itself should be able to function over HTTP. This way, if a request reaches the application through an HTTPS load balancer, the generated URLs will be HTTPS, and if a request comes directly to the application over HTTP (during development/testing), the application will generate URLs using "http://".

Given this clarified use case, the solution is to read the scheme (HTTP or HTTPS) from the incoming request rather than relying on hardcoded configurations. This allows the application to adapt to the load balancer's SSL setup.

The code changes would involve reading the http.Request object to determine the scheme and constructing the URL accordingly.

[hslatman]

Hey @amalchuk, we'll likely not read it from the request, as that could cause surprises with existing configurations. In your use case I think it would be sufficient if you were able to override the (default) scheme, would it not?

[amalchuk]

In your use case I think it would be sufficient if you were able to override the (default) scheme, would it not?

No, it wouldn't. For example, if I use lego client:

[hslatman]

We still likely won't want to make it dynamically read from the request. step-ca is designed to run over HTTPS (for the most part, at least), and for the ACME protocol HTTPS is required. If we were to change things, we'd most likely make it an explicit configuration.

What is stopping you from letting the proxy make an HTTPS request with the CAs root being trusted? That is what we document for running step-ca behind a proxy / load balancer: https://smallstep.com/docs/step-ca/certificate-authority-server-production/#proxying-step-ca-traffic. More background: #246.