ROCKET_TLS with Letsencrypt

[barqers]

I'm unable to point ROCKET_TLS to letsencrypt cert files without getting errors below:

[2019-01-15 14:11:38][rocket::config::error][ERROR] environment variable ROCKET_TLS='{certs=/ssl/cert.pem,key=/ssl/privkey.pem}' could not be parsed [2019-01-15 14:11:38][_][INFO] expected EOF but found { (eof) Logger failed to initialize: attempted to set a logger after the logging system was already initialized Logger failed to initialize: attempted to set a logger after the logging system was already initialized

I've tried certs as cert.pem and fullchain.pem and key as privkey.pem and priv-fullchain-bundle.pem which all produce the same errors.

[dani-garcia]

Did you check https://github.com/dani-garcia/bitwarden_rs/wiki/Enabling-HTTPS?

There is a problem with some cert applications that use symlinks, this might be related.

[barqers]

Did you check https://github.com/dani-garcia/bitwarden_rs/wiki/Enabling-HTTPS?

There is a problem with some cert applications that use symlinks, this might be related.

I did - I've checked all symlinks and there is at least read access for all owner/users/other.

[mprasil]

Are you running bitwarden_rs in container?

[barqers]

I am running bitwarden_rs via docker. Http was working fine. But considering I gave read access to other I should be able to have the docker container read the symlinked files. There was two locations pointing to the actual pem files.

[dani-garcia]

Not sure why that would fail, then. Make sure you are using the same format, quotes an all, just in case: -e ROCKET_TLS='{certs="/path_to_ssl/cert.pem",key="/path_to_ssl/privkey.pem"}'.

Other than that, I'm not sure.

[mprasil]

Maybe try to docker exec -ti bitwarden /bin/bash -c 'ls -la /ssl/' to see if the symlinks resolve properly inside the container.

[barqers]

Hmm so I'm using quotes, this is my -e ROCKET_TLS='{certs=/ssl/fullchain.pem,key=/ssl/privkey.pem}'

/ssl/ is mapped to the link to the folder with the symlinks. And the symlinks resolve properly using the exec command above showing -> to the proper files. I also tried linking the docker container straight to the files the symlinks are resolving to but that does not work either. I mean I could give read and write access to these files to see if it works but I'd rather not mess with the permissions on the pem files above read-level access. Any more thoughts?

[killuminiiiou]

Hmm so I'm using quotes, this is my -e ROCKET_TLS='{certs=/ssl/fullchain.pem,key=/ssl/privkey.pem}'

/ssl/ is mapped to the link to the folder with the symlinks. And the symlinks resolve properly using the exec command above showing -> to the proper files. I also tried linking the docker container straight to the files the symlinks are resolving to but that does not work either. I mean I could give read and write access to these files to see if it works but I'd rather not mess with the permissions on the pem files above read-level access. Any more thoughts?

Hello @barqers,
Did you manage to fix this issue? I'm currently encountering a similar behavior trying to setup bitwarden-rs on a Synology NAS, using Docker and Let's Encrypt certificates...
I get the same error you are mentioning when using:
ROCKET_TLS='{certs=/ssl/fullchain.pem,key=/ssl/privkey.pem}'
Removing the simple quotes around brackets seems to solve the issue for me (using Syno Docker UI). Container seems to start and run correctly.

But :
Trying to access the subdomain I configured in nginx to access bitwarden, I get the following error in bw logs:

[ERROR] TLS alert received: Message {
    typ: Alert,
    version: TLSv1_2,
    payload: Alert(
        AlertMessagePayload {
            level: Fatal,
            description: DecryptError
        }
    )
}

Looking at nginx error log, I see:

SSL: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01 error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed error:1408D07B:SSL routines:ssl3_get_key_exchange:bad signature) while SSL handshaking to upstream

So at this point, I'm not sure if the issue comes from bw or my server configuration. I have other sites configured on same server and domain, and everything is running fine.
If anyone has any thoughts, please let me know!
Thanks!

[BlackDex]

what happens if you connect to the bitwarden docker ip via https, bypassing nginx? Does that work without errors, besides maybe not being valid.

also, how do you have nginx configured to connect to bwrs?
Via a proxy pass? Did you also set the proxy_ssl_verify to off? http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ssl_verify

[killuminiiiou]

Hey @BlackDex, thanks for your help!
When trying to bypass nginx (I mean trying to access directly the container using https://nas_ip:container_port), I get the same error as above in bwrs logs. So I would guess there is an issue with my certificate (using chrome, ERR_SSL_PROTOCOL_ERROR is returned, saying the site can't provide a secure connection).

And yes, I'm using a proxy pass to connect to bwrs in nginx. I didn't have the option proxy_ssl_verify specified to off, I gave it a shot but still getting the same error. I'll continue investigating and keep you updated.

Thanks!

[killuminiiiou]

I found the issue... As I tried many configurations, container was pointing to a directory on the NAS where the certificates were stored, but using symlinks (which is not supported as the documentation states).

Now I'm able to connect to bwrs using https. Another issue seems to be happening:
I configured bwrs on my server on https://mysubdomain.mydomain.com/bwrs/. But it seems bwrs needs something like https://bwrs.mydomain.com to work properly (api is not reachable in the first configuration).

Thanks all for your help, I'm making progress now!

[BlackDex]

@killuminiiiou, your welcome :). indeed running bitwarden on a sub-url is not possible at this point except when modifying the vault code as stated in #241

[mprasil]

I'm going to close this as we haven't heard from @barqers for couple weeks, so hopefully this has been resolved, but feel free to re-open if issue persists.