I feel in a bit of a bind currently.
I know that wireguard is secure on its own but because https is a hard requirement for apps we cannot get to use the app without setting it up somehow.
Currently we are having people access a webserver on our internal network by connecting with wireguard then they access the server with
wireguard-gateway-ip:port. Currently this is only with http.
Also to add more convolution we have it on their home network which has a dynamic IP so are using dynu for DDNS, with wireguard pointing to the dynu subdomain.
I made a certificate with lets encrypt for the dynu subdomain and then tried accessing the webserver with
https://<wireguard-ip> but the browser produced the warning message:
<wireguard-gateway-ip> uses an invalid security certificate.
The certificate is only valid for *.<dynu-subdomain>
(Error code: SSL_ERROR_BAD_CERT_DOMAIN)
I am really getting kind of stuck for how to resolve this? We need ssl for app functionality as the majority of users will want to use the mobile app yet at the same time do not know how to achieve this since ssl certs are not issued for IP addresses and the only way I know to connect to the server is via the wireguard gateway ip. We used a VPN for security rather than opening ports on their home router but it feels we are backed into a corner now due to this.
Is there any way out?
We want to keep VPN access while somehow being able to have ssl functionality on the webserver.
Welcome @user87564 to the community
That is true for Let's Encrypt certs but other CA's offer certs for IP addresses. I do not know if any free CA offer that but I saw paid ones just googling: ssl cert for ip address
I don't understand your config well enough to suggest any clever way to use Let's Encrypt. But, perhaps some other volunteers will.
This is a DIY/open source/pet project so not intending to pay for any certs.
Given that this is running in Wireguard, I presume the "gateway ip" you're talking about is a RFC1918 address?
If so, you won't find any publicy trusted CA issuing a certificate for that IP, as it's not unique and cannot be verified.
What you can do is setup a domain that points to whatever (internal) IP you want and get a cert for that domain via Let's Encrypts DNS-01 challenge. When connecting use the domain name rather than the raw IP.
Another option would be to setup your own CA and trust that locally.
The whole reason we went with vpn is due to it being a home network and so did not want to expose ports so went with a vpn for security reasons.
DNS challenge is what I was going to use either way since we are not opening ports and 443 + 80 are blocked on the router anyhow.
We can't have a domain set to internal ip though can we? since the vpn is in the middle? Due to abovementioned vpn choice, the only way to access is via vpn ip.
So it would have to be
domain-name -> vpn-gateway -> internal-ip-of-webserver right?
Regarding the option of a self signed signed cert and trusting locally, is it possible to do that without the end user getting a load of warnings? I mean since they are on our vpn already, can it be trusted in there somehow without their devices throwing a warning like would normally be the case for a self-signed cert? We are wanting easy adoption for non-tech savvy users so must make things as smooth as can be.
Why is that exactly, I'm curious? You can't just use a hostname?
Also, a while ago I found some Chinese ACME server issuing certificates for IP addresses with the ACME server address https://acme.pki.plus/acme/directory, however, it seems to be down or completely gone: the DNS address doesn't resolve.
I don't know, I am new to using wireguard and I set it up according to tutorials and that is just how it is working.
I have set it up with ddns which has a subdomain which wireguard is pointing to, however the webserver is only accessible with the vpn's gateway ip and not with the subdomain.
If the VPN is remote, operated by a third-party, then you have failed to overcome your "security reasons" concerns.
If the VPN is local, and operated by you, then it is essentially doing what you didn't want to do: "did not want to expose ports". Furthermore, it is literally exposing the entire internal network to the connected VPN client.
That said, "security" is always in a trade-off with "usability".
Adding a VPN to access internal resources seems like a highly difficultly / low usability score.
But might not rank that high on the security scale either.
I don't know what service(s) you are trying to secure, so I can't begin to recommend any other secure and usable approach.
The VPN gateway should be able to obtain and use an LE cert.
Through which you should be able to reach internal resources.
From nowhere can you ever use
That "IP as a name" is not included in the cert.
You should be to access
[this may require some "DNS tricks" when accessing it from within the local network]
If it fails, then you need to review their VPN/TLS(SSL) setup instructions.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.