Cannot login anymore after switch to OIDC in latest update
-
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.htmlcurl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
root@b2c17152-3055-4792-bf0a-5d814fe31739:/app/code# -
@buesching does this mean that the first two steps succeded and only the last one fails? If it's possible to access your setup, can you write to support@cloudron.io, I am happy to debug.
-
Hello, it is still not working. Is there a step by step guide for OIDC in Bookstack? We are using a wildcard certificate.
We have internal DNS entries for my.domain.de and bookstack.domain.de. The addresses aren't reachable from the internet. The error is the "OIDC Discovery Error" as shown above. -
@buesching If we can access your setup, please write to support@cloudron.io . Otherwise, if the certs are valid, I don't see why curl is failing.
-
Having the same issue here and since I'd like to use BookStack for co-authoring in my business in an ongoing project this is critical for me. Current work-a-round is to install bookstack outside of Cloudron and use other authentication mechanisms but I'd love to have it working
Any information on how to resolve this?
Problem-Description:
BookStack fails on login attempt when trying to "Login with Cloudron" and returns this error:
OIDC Discovery Error: HTTP request failed during discovery with error: cURL error 60: SSL certificate problem: self-signed certificate (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://[MY-DOMAIN-AND-SUBDOMAIN]/openid/.well-known/openid-configuration
Expected behavior:
- Login should succede or give alternative login method with local authentication mechanism of BookStack
Actual behavior:
- Login fails with described error message.
What I have tried so far:
- Loaded Backup of earlier installs when App was working but similar behavior now
curl -v https://[MY-DOMAIN-AND-SUBDOMAIN]/.well-known/openid-configuration
yields the expected result- Ensured that IPv4 and IPv6 (Public) are detected by Cloudron, renewed all DNS-Entries and renewed all Certs
- In Cloudron Under Settings > Networking added my local Network as trusted IP-range
- Rebootet all participating systems (Cloudron, Proxmox, pfSense, WIFI-AP)
- Created a blank new BookStack instance. Identical issue when trying to do first-login via OIDC
On the setup and last known changes:
- Operating Cloudron inside a VM on my local Proxmox in my home-network
- Have fixed IPv4 from my ISP which is forwarded to Cloudron instance
- Installed a pfSense last week so: Internet (ISP) => Modem (ISP) in bridged Mode => pfSense => Internal Network with Cloudron being one of them
To me it looks like there is a static(?) cert missing in the BookStack App.
Any advise on how to proceed? Thank you in advance!
Jan
-
@nebulon ok, this seems to be a NAT Reflection aka hairpinning issue. When trying to run the
curl -v https://[MY-DOMAIN-AND-SUBDOMAIN]/.well-known/openid-configuration
inside the BookStack Container, I can see that it tries to reach out to the public IPv4.Apparently this can be fixed by either configuring NAT Reflection or Split DNS but I wonder if we could fix it by adding a loobkack entry in
/etc/resolve.con
or/etc/hosts
that points to the IP or Cloudron-Host directly to also make this work in private-network setups without "additional networking acrobatics" . Apparently these are mounted as read-only on the container. Can you advise on where to edit this? -
@Jan-Macenka Cloudron uses a DNS server called unbound internally. See https://docs.cloudron.io/networking/#private-dns . All the DNS queries go via unbound, so you have to maybe fix up unbound based on your setup (instead of editing /etc/hosts which won't solve it for apps that use DNS).
-
@girish and @nebulon thanks a lot (as always, I really love the amount of support you provide!)
Effectively everything was already documented here, and I just had to connect the dots.
What worked for me:
- Login to the Cloudron-Server via SSH
- Create this file
sudo touch /etc/unbound/unbound.conf.d/cloudron-local.conf
- Edit the file with this content
sudo nano /etc/unbound/unbound.conf.d/cloudron-local.conf
:
server: # Local zone definitions local-zone: "<YOUR_DOMAIN_HERE>." typetransparent local-data: "<YOUR_SUB_DOMAIN_HERE>.<YOUR_DOMAIN_HERE>. IN A <YOUR_STATIC_IP_HERE>"
so for example:
server: # Local zone definitions local-zone: "example.com." typetransparent local-data: "my.example.com. IN A 10.10.0.3"
- Reboot the system
This should hopefully also fix this for other Apps that need to resolve this.
UPDATE: Damn... this fixed the immediate issue but after some more dabbling, I found that this had some side-effects where other Apps seem to have trouble connecting properly... Will work on this some more and update you if I find a workable solution.
-
@Jan-Macenka said in Cannot login anymore after switch to OIDC in latest update:
UPDATE: Damn... this fixed the immediate issue but after some more dabbling, I found that this had some side-effects where other Apps seem to have trouble connecting properly... Will work on this some more and update you if I find a workable solution.
Can you explain this a bit more? What other apps have problems? Maybe you just have them too to local-data ?
-
@girish when trying to use Roundcube (Email), it states that "Verbindung zum Speicherserver fehlgeschlagen" (Connection to storage server failed). Also when I try to go to Cloudron-Web-UI > Settings > Email, I always get a re-direct to the
/#/apps
path.I disabled the
/etc/unbound/unbound.conf.d/cloudron-local.conf
file but same result.Any advise where to debug this?
-
@Jan-Macenka OK, so this fails regardless of the unbound configuration . Have you enabled Cloudron email in the first place? On a side note, it's quite unlikely that running Email from an internal network (and no hairpinning) will work.
-
Ok, after same more debugging with @girish it turned out that this solution works as intended.
My Email-Services stopped working which was due to a change in local name resolution. Restarting the Email-Server and updating some configurations in my Firewall solved the issue.
-