I was setting up litebastion on a server where port 443 was already used for something else, so I configured litebastion to use another port number using -listen 0.0.0.0:3333. From what I could see on the bastion server itself, litebastion was up and running and there was no error message indicating any trouble. But clients could not connect, and it turned out to be because it had no TLS certificate and it failed to get a certificate because the ALPN ACME challenge tries to use port 443 which on this server was used for something else.
The cmd/litebastion/README.md file says the following:
Since litebastion needs to operate at a lower level than HTTPS on the witness
side, it can't be behind a reverse proxy, and needs to configure its own TLS
certificate. Use the `-cache`, `-email`, and `-host` flags to configure the ACME
client. The ALPN ACME challenge is used, so as long as the `-listen` port
receives connections to the `-host` name at port 443, everything should just
work.
So, it's not strange that it did not work, arguably the user (me) should have read the documentation and understand that port 443 is needed.
But I do think that the behavior of litebastion in this case is confusing. Clients that try to connect just end up waiting until a timeout, presumably because litebastion is trying (failing) to get a certificate. On the bastion server side, there is no error message and also no log message at all related to the TLS certificate configuration. So the situation is unclear, things are not working and there is no clear indication of why.
One thing the user can do is to look in the chosen -cache directory (directory to cache ACME certificates at) and see that no certificate files have appeared there, and in this way figure out that there is a problem with the ALPN ACME challenge.
It would have been helpful if there was an error message saying that the ALPN ACME challenge failed.
Another thing that would have helped is if there was an informational log message before ("Trying to get cert") and after each attempt to get a certificate ("Successfully got cert"). Then the user could see the message about trying but no message about success, and understand that there was a problem.
Related to #9
I was setting up litebastion on a server where port 443 was already used for something else, so I configured litebastion to use another port number using
-listen 0.0.0.0:3333. From what I could see on the bastion server itself, litebastion was up and running and there was no error message indicating any trouble. But clients could not connect, and it turned out to be because it had no TLS certificate and it failed to get a certificate because the ALPN ACME challenge tries to use port 443 which on this server was used for something else.The cmd/litebastion/README.md file says the following:
So, it's not strange that it did not work, arguably the user (me) should have read the documentation and understand that port 443 is needed.
But I do think that the behavior of litebastion in this case is confusing. Clients that try to connect just end up waiting until a timeout, presumably because litebastion is trying (failing) to get a certificate. On the bastion server side, there is no error message and also no log message at all related to the TLS certificate configuration. So the situation is unclear, things are not working and there is no clear indication of why.
One thing the user can do is to look in the chosen
-cachedirectory (directory to cache ACME certificates at) and see that no certificate files have appeared there, and in this way figure out that there is a problem with the ALPN ACME challenge.It would have been helpful if there was an error message saying that the ALPN ACME challenge failed.
Another thing that would have helped is if there was an informational log message before ("Trying to get cert") and after each attempt to get a certificate ("Successfully got cert"). Then the user could see the message about trying but no message about success, and understand that there was a problem.
Related to #9