[GH-ISSUE #290] Unable to connect via HTTPS (RSA_padding_check_PKCS1_type_1:block type is not 01) #157

New issue

Closed

opened 2026-03-03 01:26:00 +03:00 by kerem · 3 comments

kerem commented

2026-03-03 01:26:00 +03:00

Owner

Originally created by @TomasTokaMrazek on GitHub (Dec 14, 2018).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/290

I'm using Synology NAS with configured nginx reverse proxy and docker. Almost everything was set up via GUI, so there might be other issue. Anyway, here's snippert of docker inspect HostConfig


            "Binds": [
                "/volume1/docker/bitwarden/ssl:/ssl:rw",
                "/volume1/docker/bitwarden/data:/data:rw"
            ],
            "ContainerIDFile": "",
            "LogConfig": {
                "Type": "db",
                "Config": {}
            },
            "NetworkMode": "bridge",
            "PortBindings": {
                "3012/tcp": [
                    {
                        "HostIp": "0.0.0.0",
                        "HostPort": "16012"
                    }
                ],
                "443/tcp": [
                    {
                        "HostIp": "0.0.0.0",
                        "HostPort": "16443"
                    }
                ]
            },
            "Env": [
                "ROCKET_TLS={certs=\"/ssl/chain.pem\",key=\"/ssl/privkey.pem\"}",
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
                "ROCKET_ENV=staging",
                "ROCKET_PORT=443",
                "ROCKET_WORKERS=3"
            ]
        },

nginx configuration:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name bitwarden.customdomain.cz;

    ssl_certificate /usr/syno/etc/certificate/ReverseProxy/301169fd-70f8-45c7-845c-56a3e12acb21/fullchain.pem;

    ssl_certificate_key /usr/syno/etc/certificate/ReverseProxy/301169fd-70f8-45c7-845c-56a3e12acb21/privkey.pem;

    location / {

        proxy_connect_timeout 60;

        proxy_read_timeout 60;

        proxy_send_timeout 60;

        proxy_intercept_errors off;

        proxy_http_version 1.1;

        proxy_set_header        Host            $http_host;

        proxy_set_header        X-Real-IP            $remote_addr;

        proxy_set_header        X-Forwarded-For            $proxy_add_x_forwarded_for;

        proxy_set_header        X-Forwarded-Proto            $scheme;

        proxy_pass https://localhost:16443;

    }

    error_page 403 404 500 502 503 504 @error_page;

    location @error_page {
        root /usr/syno/share/nginx;
        rewrite (.*) /error.html break;
        allow all;
    }

}

Certificate is generated automatically by Let's Encrypt and is most definitely valid, but it's primary domain is different, it's acutally dsm.customdomain.cz with alias to bitwarden.*.cz

Error raised in nginx reverse proxy error.log

2018/12/14 01:33:50 [crit] 2372#2372: 62723 SSL_do_handshake() failed (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, client: 83...**, server: bitwarden.customdomain.cz, request: "GET / HTTP/1.1", upstream: "https://127.0.0.1:16443/", host: "bitwarden.customdomain.cz"

I would normally suspect that the error is on my side, but I have the set up quite a few other services with same proxy settings, albeint not in docker. I also tried to remove rsa_key from /data volume, since I was previously logged via HTTP.

Originally created by @TomasTokaMrazek on GitHub (Dec 14, 2018). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/290 I'm using Synology NAS with configured nginx reverse proxy and docker. Almost everything was set up via GUI, so there might be other issue. Anyway, here's snippert of docker inspect HostConfig ``` "Binds": [ "/volume1/docker/bitwarden/ssl:/ssl:rw", "/volume1/docker/bitwarden/data:/data:rw" ], "ContainerIDFile": "", "LogConfig": { "Type": "db", "Config": {} }, "NetworkMode": "bridge", "PortBindings": { "3012/tcp": [ { "HostIp": "0.0.0.0", "HostPort": "16012" } ], "443/tcp": [ { "HostIp": "0.0.0.0", "HostPort": "16443" } ] }, "Env": [ "ROCKET_TLS={certs=\"/ssl/chain.pem\",key=\"/ssl/privkey.pem\"}", "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "ROCKET_ENV=staging", "ROCKET_PORT=443", "ROCKET_WORKERS=3" ] }, ``` nginx configuration: ``` server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name bitwarden.customdomain.cz; ssl_certificate /usr/syno/etc/certificate/ReverseProxy/301169fd-70f8-45c7-845c-56a3e12acb21/fullchain.pem; ssl_certificate_key /usr/syno/etc/certificate/ReverseProxy/301169fd-70f8-45c7-845c-56a3e12acb21/privkey.pem; location / { proxy_connect_timeout 60; proxy_read_timeout 60; proxy_send_timeout 60; proxy_intercept_errors off; proxy_http_version 1.1; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_pass https://localhost:16443; } error_page 403 404 500 502 503 504 @error_page; location @error_page { root /usr/syno/share/nginx; rewrite (.*) /error.html break; allow all; } } ``` Certificate is generated automatically by Let's Encrypt and is most definitely valid, but it's primary domain is different, it's acutally dsm.customdomain.cz with alias to bitwarden.*.cz Error raised in nginx reverse proxy error.log 2018/12/14 01:33:50 [crit] 2372#2372: *62723 SSL_do_handshake() failed (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, client: 83.***.***.***, server: bitwarden.customdomain.cz, request: "GET / HTTP/1.1", upstream: "https://127.0.0.1:16443/", host: "bitwarden.customdomain.cz" I would normally suspect that the error is on my side, but I have the set up quite a few other services with same proxy settings, albeint not in docker. I also tried to remove rsa_key from /data volume, since I was previously logged via HTTP.

kerem closed this issue

2026-03-03 01:26:00 +03:00

kerem commented

2026-03-03 01:26:01 +03:00

Author

Owner

@TomasTokaMrazek commented on GitHub (Dec 14, 2018):

Ok, I found the issue.

ROCKET_TLS needs a path to the full chain (cert + chain), not just a chain. Closing and keeping for further reference.

By the way, Synology DSM Certificate export does not include full chain, you have to create it by simply copying cert and chain into one file.

@TomasTokaMrazek commented on GitHub (Dec 14, 2018): Ok, I found the issue. ROCKET_TLS needs a path to the full chain (cert + chain), not just a chain. Closing and keeping for further reference. By the way, Synology DSM Certificate export does not include full chain, you have to create it by simply copying cert and chain into one file.

kerem commented

2026-03-03 01:26:01 +03:00

Author

Owner

@geimist commented on GitHub (Dec 14, 2018):

I configured the DiskStation to create the Let's Encrypt certificate including an alias for Bitwarden. A script checks daily if the certificate has been renewed and copies it to the mounted Bitwarden SSL folder if necessary.

Here you can find the script [LINK]

@geimist commented on GitHub (Dec 14, 2018): I configured the DiskStation to create the Let's Encrypt certificate including an alias for Bitwarden. A script checks daily if the certificate has been renewed and copies it to the mounted Bitwarden SSL folder if necessary. Here you can find the script [[LINK](https://www.synology-forum.de/showthread.html?90435-Bitwarden-auf-der-Synology-%28Docker%29&p=750679&viewfull=1#post750679)]

kerem commented

2026-03-03 01:26:01 +03:00

Author

Owner

@aledexter commented on GitHub (May 1, 2020):

Ok, I found the issue.

ROCKET_TLS needs a path to the full chain (cert + chain), not just a chain. Closing and keeping for further reference.

By the way, Synology DSM Certificate export does not include full chain, you have to create it by simply copying cert and chain into one file.

Do you have a link to any guide to do it?
Generation of selfsigned Sino certificates and, after that, in what order we have to copy and paste into one file?

@aledexter commented on GitHub (May 1, 2020): > Ok, I found the issue. > > ROCKET_TLS needs a path to the full chain (cert + chain), not just a chain. Closing and keeping for further reference. > > By the way, Synology DSM Certificate export does not include full chain, you have to create it by simply copying cert and chain into one file. Do you have a link to any guide to do it? Generation of selfsigned Sino certificates and, after that, in what order we have to copy and paste into one file?

kerem referenced this issue

2026-03-03 02:20:11 +03:00

[PR #159] [MERGED] Allow non-Admin user to share to collection (fixes #157) #2642