Cannot login anymore after switch to OIDC in latest update

[girish]

@buesching This is what I have in /etc/unbound/unbound.conf.d/custom.conf:

server:

local-zone: smartserver.io typetransparent
local-data: "my.smartserver.io A 172.18.0.1"
local-data: "my.smartserver.io AAAA fd00:c107:d509::1"

Then, systemctl restart unbound

To verify (44dea384c5b0 is the bookstack container. you can do docker ps to find the bookstack container) :

root@ubuntu-8gb-nbg1-1:~# docker exec -ti 44dea384c5b0 /bin/bash
root@ff31e413-a6d2-4914-bccb-5eeef305839c:/app/code# host my.smartserver.io
my.smartserver.io has address 172.18.0.1
my.smartserver.io has IPv6 address fd00:c107:d509::1

The above confirms our unbound is working.

Then:

root@ff31e413-a6d2-4914-bccb-5eeef305839c:/app/code# curl https://my.smartserver.io/openid/.well-known/openid-configuration
{"authorization_endpoint":"https://my.smartserver.io/openid/auth","claims_parameter_supported":false,"claims_supported":["sub","email","email_verified","family_name","given_name","locale","name","preferred_username","sid","auth_time","iss"],"code_challenge_methods_supported":["S256"],"grant_types_supported":["authorization_code","implicit","refresh_token"],"issuer":"https://my.smartserver.io/openid","jwks_uri":"https://my.smartserver.io/openid/jwks","authorization_response_iss_parameter_supported":true,"response_modes_supported":["form_post","fragment","query"],"response_types_supported":["code","id_token","id_token token","code id_token","code token","code id_token token","none"],"scopes_supported":["openid","offline_access","email","profile"],"subject_types_supported":["public"],"token_endpoint_auth_methods_supported":["client_secret_basic","client_secret_jwt","client_secret_post","private_key_jwt","none"],"token_endpoint_auth_signing_alg_values_supported":["HS256","RS256","PS256","ES256","EdDSA"],"token_endpoint":"https://my.smartserver.io/openid/token","id_token_signing_alg_values_supported":["RS256"],"pushed_authorization_request_endpoint":"https://my.smartserver.io/openid/request","request_parameter_supported":false,"request_uri_parameter_supported":false,"userinfo_endpoint":"https://my.smartserver.io/openid/me","claim_types_supported":["normal"]}

We get OIDC response. Can you check where it fails above for you?

[buesching]

curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

curl 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#

[girish]

@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.

[buesching]

The first steps are working. I get this error when trying the curl command. I am in vacation for the next week. I will text you afterwards.

[buesching]

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.

[girish]

@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.

[Jan Macenka]

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]

Looking at the server from the created support ticket, this is also the same hairpinning issue as described earlier in the thread.

[Jan Macenka]

@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?

[girish]

@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).

[Jan Macenka]

@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:

1. Login to the Cloudron-Server via SSH
2. Create this file sudo touch /etc/unbound/unbound.conf.d/cloudron-local.conf
3. 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"

4. 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.

[girish]

@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 ?

[Jan Macenka]

@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?

[girish]

@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.

[Jan Macenka]

@girish answered you in direct chat. If we have results that are of public interest, we can publish it here afterwards

[Jan Macenka]

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.