mirror of
https://github.com/FiloSottile/mkcert.git
synced 2026-04-25 05:26:03 +03:00
[GH-ISSUE #106] Integrated server #58
Labels
No labels
TLS stack issue
Windows
bug
duplicate
duplicate
enhancement
help wanted
help wanted
pull-request
question
question
root store
waiting for info
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/mkcert#58
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @rrader on GitHub (Jan 8, 2019).
Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/106
Hi
It's really nice idea to have a tool like this to spin up secure servers for development.
What I think is missing here to cover this use-case is a simple utility to run a server with generated certificate.
I think this should work something like
mkcert serve --listen 0.0.0.0:8080 --reverse-proxy 127.0.0.1:8081So if we just need to check some application how it's working with HTTPS terminated on front-end server, we run this command and set up reverse proxy to our application.
Important thing that headers like X-Forwarded-Proto should be passed to the end application.
What do you think?
@mdkozlowski commented on GitHub (Jan 8, 2019):
I'd be happy to contribute to this if the owner would like it included
@FiloSottile commented on GitHub (Jan 8, 2019):
Hmm, I like mkcert being a focused tool, and once you start adding features to a reverse proxy you never stop, but this sounds useful.
I wonder if it would be solved just as well by the ACME server mode, paired with Caddy. Maybe we should just make a mkcert plugin for Caddy (following #45)? @mholt?
@mholt commented on GitHub (Jan 8, 2019):
Yeah, someone mentioned in the Caddy Slack that this would be a good way to implement
tls self_signedwithin Caddy.Right now, self-signed certs in Caddy is very simple: just hard-coded and stored in memory, but we could make it extensible without too much trouble...
@whitestrake commented on GitHub (Jan 9, 2019):
If a
mkcertplugin for Caddy were to be implemented, the equivalent command to the example given in the OP would becaddy -port 8080 "proxy / 127.0.0.1:8081" "tls mkcert"(wheretls mkcertis a proposed method of specifying amkcertcertificate instead of a traditionalself_signedone).I'd be pretty happy to see this happen.
Once
mkcertcan act as an ACME server, Caddy is already positioned to make use of it with the-caflag (which sets the ACME endpoint Caddy will use to requisition its certificates). But I think it would be very nice to seemkcertitself become an actual first class plugin compiled into Caddy itself.@mholt commented on GitHub (Jan 9, 2019):
Ooo, good point, if mkcert ran an ACME server, then Caddy could just use that with the
-caflag. That seems quite a bit easier (i.e. no new work to do).@whitestrake commented on GitHub (Jan 9, 2019):
A small amount of work would be required, I think, because currently Automatic HTTPS refuses to requisition certificates for non-public hostnames (since LetsEncrypt wouldn't issue those anyway). A flag might need to be added to signal to Caddy that it's talking to a
mkcertACME server so it will actually manage a certificate.It might be difficult to do this in a way that lets an end-user launch a secure reverse proxy one-liner command like OP suggested (a Caddyfile might be required, for example to specify which hostname(s) the certificate should be issued for, or perhaps Caddy could be programmed to assume
localhostand127.0.0.1?).@mholt commented on GitHub (Jan 9, 2019):
@whitestrake
Are you sure? In theory, any ACME-compliant server should work.
Granted, if it's for hostnames like
localhostor IP addresses, things get different; but trusted certs aren't issued for IP addresses anyways, and localhost is a secure origin.@whitestrake commented on GitHub (Jan 9, 2019):
Aye, but it'd have to be handled specially somehow since at the moment, Caddy won't bother even contacting the ACME server unless it thinks you're using a publicly accessible domain name (which
localhost, an IP address, or a variety of other certificates local devs might use wouldn't qualify as). These kinds of site labels would disable Caddy's Automatic HTTPS, leaving those sites running HTTP on port 2015 by default, without ever trying to get a cert regardless of which ACME server you pointed it at.Unless I'm mistaken, either the Automatic HTTPS feature would need to be modified to detect or be configured to utilise an ACME server that does issue certificates with those kinds of names (in contrast to LetsEncrypt), OR
mkcertwould need to be handled specifically as a plugin via the library option.@daquinoaldo commented on GitHub (Feb 22, 2019):
Hi,
I don't know if this thread is the good place, but I'll vary glad if mkcert will have an integrated server.
Also a simpler and smaller thing than the one proposed should be enough.
In my idea should be something like
mkcert -serve /local/path -port 8080, and mkcert just start a http2 server on that port using a self-generated certificate. It would be very useful to test on localhost over https, needed for example for testing PWAs.I've experimented a bit by myself creating sserve, trying to reach a similar result, but it will be more effectiveness if it will be integrated directly inside mkcert itself.
Despite the 250+ code rows in my implementation, integrating it inside mkcert should be very small and lightweight, I expect something around 50-70 code rows. Obviously should be something simpler, e.g. w/o minify an gzip.
If you are interested in adding this functionality I'll be glad to help, opening a curated pull request.
@FiloSottile commented on GitHub (Jun 1, 2019):
Spent some time thinking about this, and I decided it's out of scope for mkcert. I'd rather it be used via ACME for the web server of your choice. (See #154.)