Cannot login anymore after switch to OIDC in latest update

[girish]

@buesching said in Cannot login anymore after switch to OIDC in latest update:

But it is still not working

Can you tell us what is not working?

a) Can users reach the cloudron dashboard?
b) Is the app not able to reach the cloudron oidc api? Like maybe nothing appears after you click oidc button in browser?
c) Is that wildcard certificate self signed?

If c) is the issue then fixing unbound won't help here. Most apps do not accept self signed certs for oidc. I recommend simply using a proper wildcard cert. You can either switch to one of the Cloudron supported DNS providers OR purchase a wildcard cert (it's only 45usd at https://www.garrisonhost.com/ssl-certificates/alphassl). In either case, you can keep your setup completely private as now.

[buesching]

@girish
a) yes
b) same error as in the 4th post. See above.
c) it is not self signed. Its from geotrust.

We had the same problem in our environment. It was an misconfiguration of our reverse proxy (from the firewall).
In the environment of the customer the dashboards are note accessible from the internet. In that case the traffic does not run over the reverse proxy. The connection is established locally.

[girish]

@buesching Ah, all right. So, your issue looks like bookstack cannot contact cloudron dashboard because of the reverseproxy not looping back http requests. Is this sorted out now? Or are you still looking for assistance?

[girish]

If you are looking for some DNS solution to avoid the reverse proxy, you have to add something like this to unbound custom config:

server:

local-zone: example.com typetransparent
local-data: "my.example.com A 172.18.0.1"

example.com is your dashboard domain . 172.18.0.1 is the internal oidc server for the app can reach.

[buesching]

@girish In our environment everything ist working fine now.

[buesching]

@girish
I changed my unbound config. I restarted the unbound service. Still get this error when trying to login.

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