Bitwarden Container does not start with newly generated certificates #387

New Issue

Closed

opened 2026-02-04 20:12:19 +03:00 by OVERLORD · 3 comments

OVERLORD commented 2026-02-04 20:12:19 +03:00

Owner

Copy Link

Originally created by @seehma on GitHub (Aug 25, 2019).

Hi,

hope iam not discussing an allready discussed issue but i have problems with my newly generated letsencrypt certificates. Those certificates are working well on a nextcloud container but not in bitwarden.
I have version 1.9.1 running on docker on a Synology NAS. With the old certificates it is working fine (they are in the same directory just renamed cert.pem_working and privkey.pem_working).

However i have in the same directory the new generated certificates and with them the bitwarden container wont start anymore. I get the following error:

Again if i switch to my old certificates which are located right beside the new ones, everything works fine.

Iam also using the same certificates for my synology NAS and there they are also working fine.

Thats my settings:

Any suggestions?

Thx for help in advance!

M.

Originally created by @seehma on GitHub (Aug 25, 2019). Hi, hope iam not discussing an allready discussed issue but i have problems with my newly generated letsencrypt certificates. Those certificates are working well on a nextcloud container but not in bitwarden. I have version 1.9.1 running on docker on a Synology NAS. With the old certificates it is working fine (they are in the same directory just renamed cert.pem_working and privkey.pem_working).  However i have in the same directory the new generated certificates and with them the bitwarden container wont start anymore. I get the following error:  Again if i switch to my old certificates which are located right beside the new ones, everything works fine. Iam also using the same certificates for my synology NAS and there they are also working fine. Thats my settings:  Any suggestions? Thx for help in advance! M.

OVERLORD closed this issue 2026-02-04 20:12:25 +03:00

OVERLORD commented 2026-02-04 20:12:27 +03:00

Author

Owner

Copy Link

@Ayitaka commented on GitHub (Aug 25, 2019):

According to the Rocket source code...

/// Sets the TLS configuration in self.
///
/// Certificates are read from certs_path. The certificate chain must be
/// in X.509 PEM format. The private key is read from key_path. The
/// private key must be an RSA key in either PKCS#1 or PKCS#8 PEM format.
///
/// # Errors
///
/// If reading either the certificates or private key fails, an error of
/// variant Io is returned. If either the certificates or private key
/// files are malformed or cannot be parsed, an error of BadType is
/// returned.

Sounds like something is wrong the with private key. (Maybe copied the wrong file?) Double check that the format of the private key is correct starting with:

----BEGIN PRIVATE KEY-----

then long lines of equally sized text, and ending with:

-----END PRIVATE KEY-----

Lets Encrypt apparently issues PKCS#10 PEM formatted certificates, according to their API documentation, but since their default certs work fine for me and others I have to assume it has nothing to do with the "key in either PKCS#1 or PKCS#8" bit.

Just some places to start checking, sorry I can't be more specific with an answer for you.

@Ayitaka commented on GitHub (Aug 25, 2019): According to the [Rocket source code](https://github.com/SergioBenitez/Rocket/blob/fe4fd3e2412df690249352480395ca9fa6db0124/core/lib/src/config/config.rs)... > /// Sets the TLS configuration in `self`. > /// > /// Certificates are read from `certs_path`. The certificate chain must be > /// in X.509 PEM format. The private key is read from `key_path`. The > /// private key must be an RSA key in either PKCS#1 or PKCS#8 PEM format. > /// > /// # Errors > /// > /// If reading either the certificates or private key fails, an error of > /// variant `Io` is returned. If either the certificates or private key > /// files are malformed or cannot be parsed, an error of `BadType` is > /// returned. Sounds like something is wrong the with private key. (Maybe copied the wrong file?) Double check that the format of the private key is correct starting with: > ----BEGIN PRIVATE KEY----- then long lines of equally sized text, and ending with: > -----END PRIVATE KEY----- Lets Encrypt apparently issues PKCS#10 PEM formatted certificates, according to [their API documentation](https://tools.ietf.org/html/draft-ietf-acme-acme-09), but since their default certs work fine for me and others I have to assume it has nothing to do with the "key in either PKCS#1 or PKCS#8" bit. Just some places to start checking, sorry I can't be more specific with an answer for you.

OVERLORD commented 2026-02-04 20:12:41 +03:00

Author

Owner

Copy Link

@seehma commented on GitHub (Aug 31, 2019):

Hi, i checked if the file has the right beginning and ending. The only difference was that i had
-----BEGIN RSA PRIVATE KEY-----
I tried to change this to
-----BEGIN PRIVATE KEY-----
and of course the same on the end of the file, but i get the same error message again.
One more difference to the old working certificates is that the cert.pem file has to begin and end blocks. i dont know why but as i said in Nextcloud it is working perfectly fine.

@seehma commented on GitHub (Aug 31, 2019): Hi, i checked if the file has the right beginning and ending. The only difference was that i had `-----BEGIN RSA PRIVATE KEY-----` I tried to change this to `-----BEGIN PRIVATE KEY-----` and of course the same on the end of the file, but i get the same error message again. One more difference to the old working certificates is that the cert.pem file has to begin and end blocks. i dont know why but as i said in Nextcloud it is working perfectly fine.

OVERLORD commented 2026-02-04 20:12:54 +03:00

Author

Owner

Copy Link

@seehma commented on GitHub (Aug 31, 2019):

Hi, i tried some more things including a new certificate with a new subdomain and this works now. The other certificate was valid for two domains -> bw.mydomain.at and secondname.mydomain.at

The new certificate is only valid for bw2.mydomain.at and now it looks like this is ok for bitwarden (ROCKET_TLS).

@seehma commented on GitHub (Aug 31, 2019): Hi, i tried some more things including a new certificate with a new subdomain and this works now. The other certificate was valid for two domains -> bw.mydomain.at and secondname.mydomain.at The new certificate is only valid for bw2.mydomain.at and now it looks like this is ok for bitwarden (ROCKET_TLS).

OVERLORD referenced this issue 2026-02-05 04:53:36 +03:00

[PR #387] [MERGED] Update revision when adding or removing cipher from collection #2696

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

cached-config-operations

test_dylint

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 Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

OVERLORD

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#387