starred/vaultwarden
1
0
Fork 0
mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-04-25 17:25:57 +03:00
Code Issues 39 Projects Releases 5 Packages Wiki Activity

[GH-ISSUE #340] ROCKET_TLS with Letsencrypt #191

New issue
Closed
opened 2026-03-03 01:26:30 +03:00 by kerem · 13 comments
kerem commented 2026-03-03 01:26:30 +03:00
Owner
Copy link

Originally created by @barqers on GitHub (Jan 15, 2019).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/340

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.

Originally created by @barqers on GitHub (Jan 15, 2019). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/340 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.
kerem closed this issue 2026-03-03 01:26:31 +03:00
kerem commented 2026-03-03 01:26:31 +03:00
Author
Owner
Copy link

@dani-garcia commented on GitHub (Jan 15, 2019):

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.

<!-- gh-comment-id:454414204 --> @dani-garcia commented on GitHub (Jan 15, 2019): 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.
kerem commented 2026-03-03 01:26:31 +03:00
Author
Owner
Copy link

@barqers commented on GitHub (Jan 15, 2019):

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.

<!-- gh-comment-id:454424182 --> @barqers commented on GitHub (Jan 15, 2019): > 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.
kerem commented 2026-03-03 01:26:32 +03:00
Author
Owner
Copy link

@mprasil commented on GitHub (Jan 15, 2019):

Are you running bitwarden_rs in container?

<!-- gh-comment-id:454427746 --> @mprasil commented on GitHub (Jan 15, 2019): Are you running bitwarden_rs in container?
kerem commented 2026-03-03 01:26:32 +03:00
Author
Owner
Copy link

@barqers commented on GitHub (Jan 15, 2019):

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.

<!-- gh-comment-id:454430549 --> @barqers commented on GitHub (Jan 15, 2019): 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.
kerem commented 2026-03-03 01:26:32 +03:00
Author
Owner
Copy link

@dani-garcia commented on GitHub (Jan 15, 2019):

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.

<!-- gh-comment-id:454437014 --> @dani-garcia commented on GitHub (Jan 15, 2019): 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.
kerem commented 2026-03-03 01:26:32 +03:00
Author
Owner
Copy link

@mprasil commented on GitHub (Jan 15, 2019):

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

<!-- gh-comment-id:454468804 --> @mprasil commented on GitHub (Jan 15, 2019): Maybe try to `docker exec -ti bitwarden /bin/bash -c 'ls -la /ssl/'` to see if the symlinks resolve properly inside the container.
kerem commented 2026-03-03 01:26:32 +03:00
Author
Owner
Copy link

@barqers commented on GitHub (Jan 15, 2019):

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?

<!-- gh-comment-id:454584335 --> @barqers commented on GitHub (Jan 15, 2019): 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?
kerem commented 2026-03-03 01:26:32 +03:00
Author
Owner
Copy link

@killuminiiiou commented on GitHub (Feb 5, 2019):

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!

<!-- gh-comment-id:460833074 --> @killuminiiiou commented on GitHub (Feb 5, 2019): > 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!
kerem commented 2026-03-03 01:26:32 +03:00
Author
Owner
Copy link

@BlackDex commented on GitHub (Feb 6, 2019):

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

<!-- gh-comment-id:460920744 --> @BlackDex commented on GitHub (Feb 6, 2019): 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
kerem commented 2026-03-03 01:26:32 +03:00
Author
Owner
Copy link

@killuminiiiou commented on GitHub (Feb 7, 2019):

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!

<!-- gh-comment-id:461610788 --> @killuminiiiou commented on GitHub (Feb 7, 2019): 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!
kerem commented 2026-03-03 01:26:32 +03:00
Author
Owner
Copy link

@killuminiiiou commented on GitHub (Feb 7, 2019):

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!

<!-- gh-comment-id:461620116 --> @killuminiiiou commented on GitHub (Feb 7, 2019): 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!
kerem commented 2026-03-03 01:26:32 +03:00
Author
Owner
Copy link

@BlackDex commented on GitHub (Feb 7, 2019):

@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

<!-- gh-comment-id:461626332 --> @BlackDex commented on GitHub (Feb 7, 2019): @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
kerem commented 2026-03-03 01:26:33 +03:00
Author
Owner
Copy link

@mprasil commented on GitHub (Feb 13, 2019):

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.

<!-- gh-comment-id:463146591 --> @mprasil commented on GitHub (Feb 13, 2019): 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.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
revert-7033-patch-1
cached-config-operations
test_dylint
1.35.7
1.35.6
1.35.5
1.35.4
1.35.3
1.35.2
1.35.1
1.35.0
1.34.3
1.34.2
1.34.1
1.34.0
1.33.2
1.33.1
1.33.0
1.32.7
1.32.6
1.32.5
1.32.4
1.32.3
1.32.2
1.32.1
1.32.0
1.31.0
1.30.5
1.30.4
1.30.3
1.30.2
1.30.1
1.30.0
1.29.2
1.29.1
1.29.0
1.28.1
1.28.0
1.27.0
1.26.0
1.25.2
1.25.1
1.25.0
1.24.0
1.23.1
1.23.0
1.22.2
1.22.1
1.22.0
1.21.0
1.20.0
1.19.0
1.18.0
1.17.0
1.16.3
1.16.2
1.16.1
1.16.0
1.15.1
1.15.0
1.14.2
1.14.1
1.14
1.13.1
1.13.0
1.12.0
1.11.0
1.10.0
1.9.1
1.9.0
1.8.0
1.7.0
1.6.1
1.6.0
1.5.0
1.4.0
1.3.0
1.2.0
1.1.0
1.0.0
0.13.0
0.12.0
0.11.0
0.10.0
0.9.0
Labels
Clear labels   
SSO

   
Third party

   
better for forum

   
bug

   
bug

   
documentation

   
duplicate

   
enhancement

   
future Vault

   
future Vault

   
future Vault

   
good first issue

   
help wanted

   
low priority

   
notes

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
troubleshooting

   
wontfix
No labels
SSO
Third party
better for forum
bug
bug
documentation
duplicate
enhancement
future Vault
future Vault
future Vault
good first issue
help wanted
low priority
notes
pull-request
question
troubleshooting
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/vaultwarden#191
No description provided.