Hi there,
I am currently trying to get browzer to work in our infrastructure. We are using Authentik as IDP. I installed the browzer-bootstrapper and started some initial testing. It seems I have initial things up - browzer is reachable, I also have an OriginTrail token but I only see the 'browzer' logo startup / splash screen.
On the javascript console I see messages indicating that there is a CORS problem when communicating with the IDP:
Access to fetch at 'https://auth.[redacted]/application/o/browzer-test-1/.well-known/openid-configuration' from origin 'https://test1.external.[redacted]' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
Is there a working / validated setup with Authentik? Any hints how to proceed?
Thanks & Bye,
Chris
Hi.
I found the problem - it was just a typo in the ' Redirect URI' - authentik also uses this to validate the CORS request.
I'm able to authentikate with browZer now.
Bye,
Chris
I'm so sorry I lost track of this issue and forgot to follow up! 
my bad. I'm glad you got through it though!
No problem... I'm making my way through setting it up in a kubernetes environment.
Right now I'm struggling with getting the wildcard certificates into the router. Does it also work with the alt_server_certs section? Conventions | OpenZiti
Hmm. it seems to honor the configuration
[77563.616] INFO transport/v2/wss.Listen: ws.Config{
writeTimeout 10000000000
readTimeout 5000000000
idleTimeout 120000000000
pongTimeout 60000000000
pingInterval 54000000000
handshakeTimeout 10000000000
readBufferSize 4096
writeBufferSize 4096
enableCompression true
serverCert /etc/ziti/config/core-router.server.chain.cert
key /etc/ziti/config/core-router.key
server_key
alt_server_certs[%!d(MISSING)].serverCert /etc/ziti/wss-cert/tls.crt
alt_server_certs[%!d(MISSING)].server_key /etc/ziti/wss-cert/tls.key
}
but when I try to acces the websocket url it presents it's router identity and not the let's encrypt wildcard cert from the alt_server_certs files...
As you discovered, yes it does work with alt_server_certs. One thing that's not always obvious is that the alt_server_cert must not have an overlapping SANS as your non-LE cert. Meaning, if you setup your OpenZiti overlay's self-signed certs using "my.controller.com", you must not make a LE cert valid for "my.controller.com". Doing so makes the SNI unreliable and often fails.
Does that help? Could that be the problem?
yes... that might be a pointer:
edge:
csr:
sans:
dns:
- localhost
- edge.kis.sdn.xxx
- wss.external.xxx. #<-- this is my wss url...
- transport.kis.sdn.xxx
ip:
- 127.0.0.1
thanks, will double check that!
Cool. Things start to work 
3 Likes
