Hi,
was anyone able to configure Caddy as reverse proxy?
I have configured a normal reverse proxy for my subdomain (by default it creates its own certificates), but no access from the Toniebox appears in the access log.
Switching off auto https and linking the Teddycloud certificates for this subdomain did not help either.
Any further news on this? I am quite interested to host teddycloud on my server and make it available there
You can use nginx or Haproxy as described above.
Just make sure to setup basic auth in the reverse proxy for now.
Thanks, this almost worked for me. I had to modify this slightly to pass on my client certificate, otherwise the HTTPS Client Auth of Teddycloud fails. My nginx is living outside of docker, serving multiple (sub) domains, so I just have this default/invalid server name at the top of my config:
map $ssl_client_fingerprint $toniebox {
default invalid;
"client_cert_fingerprint" my_toniebox;
}
server {
listen 0.0.0.0:443 http2 ssl;
server_name _;
ssl_certificate /teddycloud/server/fullchain.pem;
ssl_certificate_key /teddycloud/server/ca-key.key;
ssl_verify_client optional_no_ca;
location / {
if ($toniebox ~ my_toniebox)
{
proxy_pass https://127.0.0.1:4444;
proxy_ssl_certificate /teddycloud/client/client.pem;
proxy_ssl_certificate_key /teddycloud/client/client.key;
}
return 444;
}
}
I only have to support one Toniebox right now, but this can be easily extended to support multiple, however in a manual fashion.
I get an error at the line
proxy_ssl_certificate /teddycloud/client/client.pem;
nginx: [emerg] “proxy_ssl_certificate” directive is not allowed here in /data/nginx/default_host/site.conf:30
I know nginx is special with some settings but I wonder if this config is accepted by your nginx version.
I don’t need the support of multiple boxes at the moment, so I can go with the config from the other thread.
You’ll either need to mount the teddycloud volume to your nginx, or extract the certificate from the volume and make it available within the nginx container.
extracting can be done with in example docker cp teddycloud:/teddycloud/certs/client ./client
The certificate is not the problem.
The problem is that my nginx does not accept this directive inside an if inside the location directive.
nginx: [emerg] “proxy_ssl_certificate” directive is not allowed here in /data/nginx/default_host/site.conf:30
With the config from Feasibility of hosting Teddycloud - #7 by cfelder my nginx works.
Hi @cfelder - I’m struggling to get this working. Which certificates are you using here? Can you provide a map between you used files and the ones available on the teddycloud server?
certs/server/ca-key.pem
certs/server/ca-root.pem
certs/server/ca.der
certs/server/teddy-key.pem
certs/server/teddy-cert.pem
My nginx complains about teddy-key.pem not being a valid key.
Thanks for reaching out. The following should shed more light on this.
server:
openssl rsa -inform DER -in teddy-key.pem -out ttt-teddy-key.pem)openssl rsa -inform DER -in ca-key.pem -out ttt-ca-key.pem)cat teddy-cert.pem ttt-teddy-key.pem ca-root.pem ttt-ca-key.pem > ttt-fullchain.pem
ssl_certificate /etc/ssl/certs/server/ttt-fullchain.pem;
ssl_certificate_key /etc/ssl/certs/server/ttt-teddy-key.pem;
client:
ssl_client_certificate /etc/ssl/certs/client/ca.pem;
The client ca actually should not matter. We cannot use that to verify the cert.
openssl verify -CAfile ca.pem client.pem
C = DE, ST = NRW, L = D\C3\BCsseldorf, O = Boxine GmbH, CN = 1234567890CF
error 20 at 0 depth lookup:unable to get local issuer certificate
client.pem: verification failed: 20 (unable to get local issuer certificate)
That the reason why I am using
ssl_verify_client optional_no_ca;
Thanks for getting back this fast. I tried this but nginx fails to start because of certificate validation errors:
I did:
112 openssl rsa -inform DER -in teddy-key.pem -out ttt-teddy-key.pem
113 openssl rsa -inform DER -in ca-key.pem -out ttt-ca-key.pem
114 cat teddy-cert.pem ttt-teddy-key.pem ca-root.pem ttt-ca-key.pem > ttt-fullchain.pem
115 cp ttt-fullchain.pem /data/custom_ssl/npm-10/fullchain.pem
116 cp ttt-teddy-key.pem /data/custom_ssl/npm-10/privkey.pem
117 /usr/sbin/nginx -t
(/data/custom_ssl/npm-10 is the path where Nginx-Proxy-Manager expects the certs in my configuration)
this throws the following certificate validation error:
nginx: [emerg] cannot load certificate "/data/custom_ssl/npm-10/fullchain.pem": PEM_read_bio_X509() failed (SSL: error:068000DD:asn1 encoding routines::illegal padding error:0688010A:asn1 encoding routines::nested asn1 error:Field=serialNumber, Type=X509_CINF error:0688010A:asn1 encoding routines::nested asn1 error:Field=cert_info, Type=X509 error:0488000D:PEM routines::ASN1 lib)
Looks like the fullchain.pem is somehow malformed but I don’t know how. I googled around but haven’t found anything that matches this error.
I narrowed it down to ca-root.pem. As soon as ca-root.pem is part of/used as fullchain.pem. the error is thrown. openssl x509 -in ttt-fullchain.pem -text -noout works/looks fine though:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1729265846 (0x671280b6)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = DE, ST = NW, L = Duesseldorf, O = Team RevvoX, CN = TeddyCloud CA Root Cert.
Validity
Not Before: Nov 3 15:23:19 2015 GMT
Not After : Jun 24 15:23:19 2040 GMT
Subject: C = DE, ST = NW, L = Duesseldorf, O = Team RevvoX, CN = TeddyCloud Server
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:a4:1b:48:2b:e2:7a:62:58:cc:c1:97:8e:40:98:
72:67:04:03:b8:80:21:b8:e2:9f:61:1f:26:e7:3b:
a9:12:2a:2a:c6:b9:37:5f:0f:90:0e:cc:33:9f:24:
ba:99:2f:4e:5e:a5:ca:62:28:b5:4a:75:37:ce:aa:
3a:e5:71:ce:03:bd:7f:4e:24:26:02:dd:28:9b:56:
a9:46:21:f7:1e:88:15:ac:ef:71:26:cb:8f:6f:cd:
72:68:03:77:b4:f7:da:1f:07:d1:ef:74:d6:21:1c:
55:88:2b:ec:f2:da:f1:f3:ba:bb:8c:8c:81:e7:a8:
02:1a:a3:86:d8:ab:d2:63:44:10:bd:d9:50:f4:36:
fa:f6:54:19:87:5e:07:e9:26:c4:db:d6:7f:1f:f0:
6c:51:ad:09:b7:4b:3b:29:2e:79:1a:f0:d7:57:a6:
d9:1d:65:7f:15:7b:c5:32:52:81:48:b0:b3:ec:18:
6e:5d:f2:ab:06:bf:7c:38:c5:b2:2a:85:f3:48:24:
65:b9:af:16:c2:0c:8f:32:32:d4:8b:42:18:25:20:
39:77:97:72:1a:fb:10:4c:af:78:d0:69:88:55:e9:
89:fa:85:60:73:1a:f7:24:b5:83:23:e0:34:bb:31:
c2:dc:31:55:69:6c:47:15:36:5a:58:54:f8:b4:82:
ca:db
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
3B:F9:12:BD:C6:72:E5:B7:A5:08:97:E6:C1:12:56:90:16:05:A9:FC
X509v3 Authority Key Identifier:
C1:8C:E8:30:AE:C7:E5:3C:61:B0:1A:65:6E:02:09:EB:69:DE:C5:7C
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
6a:43:11:7e:a5:3d:28:d3:29:29:58:96:23:68:9e:c9:f4:ef:
85:76:bc:ce:af:73:d0:e6:d1:5d:99:ca:7e:f3:b3:db:a7:f9:
4f:80:dd:eb:40:86:85:5c:a7:2e:8b:7b:8f:bc:1d:a6:3d:fd:
11:b5:1e:0d:2a:94:71:1b:ea:ec:b6:d7:11:16:1b:53:c4:7b:
8f:57:24:31:26:c9:7d:23:6d:b9:39:4d:d3:c3:3d:75:36:ba:
f8:a2:75:cc:c9:50:74:28:75:df:57:bc:ea:82:c3:9f:b4:39:
c6:99:04:27:4a:ed:44:f2:69:c2:72:70:e5:48:a2:91:ab:0d:
0f:78:b6:7f:90:06:8f:a3:97:3a:40:e2:80:a3:0b:35:78:4b:
7d:06:5e:e4:f5:b0:28:96:f7:c0:40:61:d9:15:4d:5e:53:c4:
7e:b1:5d:66:59:05:17:76:71:43:e0:b0:f6:ec:7d:39:f1:09:
9b:2a:07:a2:28:ed:80:d7:fb:fe:f9:93:0c:ed:47:48:40:19:
1e:2f:8b:a6:7f:0d:6b:d9:c6:87:17:61:a6:ae:24:d1:fc:e9:
1a:c6:29:6a:6c:33:6c:61:0e:01:7c:ac:e5:38:23:14:05:9d:
ff:ed:aa:73:20:07:e3:67:7b:a0:ad:a4:02:3d:01:15:f5:96:
02:ac:8e:2f:9d:b2:55:73:bb:f8:02:d6:17:ef:16:f5:89:8c:
6a:a9:49:56:b9:ce:d4:e7:ca:46:e5:bf:62:d3:54:8d:a1:3b:
b1:0e:bc:5d:f2:f6:11:27:da:23:6b:46:76:94:0a:30:eb:af:
bd:ff:6a:5c:73:44:3e:88:bf:c0:de:36:f6:f7:f4:15:8e:13:
ee:55:d9:0f:9c:37:fe:39:9c:26:aa:b6:e5:5b:d7:7f:a0:f0:
3b:21:a6:6d:9b:a7:06:d7:77:2c:64:88:09:26:a9:e9:5b:7c:
4c:4b:0b:da:c2:24:4a:42:f5:ec:95:ca:2f:68:a8:6b:5f:2b:
ba:b5:87:0f:fe:50:30:14:95:4f:17:52:6d:e7:33:d5:a7:d5:
53:2e:fa:48:1b:a9:1c:ad:36:a8:18:78:f3:13:07:a6:ca:3a:
40:91:dd:e4:5e:4e:4e:22:87:46:9f:18:4a:b8:6a:63:78:45:
30:cf:94:36:74:5b:70:1d:fa:39:b7:90:ad:9f:2c:8b:96:f2:
b0:f8:f3:6b:3c:57:56:36:d0:be:a0:4d:7e:75:92:0b:35:5e:
00:9d:a6:95:3b:78:d4:60:86:5f:e0:0b:57:21:51:55:59:72:
f9:27:04:16:f9:b3:d9:87:25:29:72:8f:1a:16:ef:c6:30:c0:
67:dc:73:06:ec:93:ff:75
Do you have any idea on what could be wrong/differing from you setup here?
I am currently experiencing the same error. Have you found a solution for this?
Am I correct, by using this config, anybody would have acces to TC backend, as long as SNI is not sent? Sounds “dangerous” to me… I think there should be added mTLS verification…? Or do I miss something, that this is not needed here?
Yes, you’re correct. The backend (Boxine Emulation) is unprotected. The TCP connection is passed transparently to the backend if no SNI is present. There’s no way to inspect TCP traffic beyond the handshake (which sadly doesn’t contain an SNI in the case of the TonieBox).
mTLS in HAProxy is possible but can’t be done transparently like the Nginx hack (which is not really transparent and hardly secure).
If there was exploitable code in Teddycloud, this might be dangerous (and this is why the team doesn’t recommend public hosting).
Otherwise if somebody knows the Boxine protocol, they could read your media data from the server.
Only do this, if you’re willing to take this risk!
Thanks for coming back on this.
What you mean with “hardly secure”? My understanding is, checking client cert with mTLS is most protection you can get here. As access would be limited to only clients providing with the correct cert. How could that be unsecure? What do I miss…?
Sorry, I was referring to the way Nginx is implementing this. Nginx is acting as a man in the middle in this scenario. There might be all kinds of issues due to that (timing, replay).
But then this is not a banking application 
Hey, unfortunately I have the same problem. Does anyone have an idea?
I tried the last 3 hours to fix the problem, but no success. My error is:
fullchain.pem": PEM_read_bio_X509() failed (SSL: error:068000DD:asn1 encoding routines::illegal padding error:0688010A:asn1 encoding routines::nested asn1 error:Field=serialNumber, Type=X509_CINF error:0688010A:asn1 encoding routines::nested asn1 error:Field=cert_info, Type=X509 error:0488000D:PEM routines::ASN1 lib)
Does anyone have an idea?
My nginx:
nginx version: nginx/1.22.1
built with OpenSSL 3.0.8 7 Feb 2023 (running with OpenSSL 3.0.15 3 Sep 2024)
TLS SNI support enabled
My nginx settings:
server {
## TeddyCloud subdomain
listen 443 ssl;
server_name DOMAIN;
ssl_protocols SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ALL:!aNULL;
# Server's certificate and private key
ssl_certificate /etc/nginx/certs/teddycloud/server/fullchain.pem;
ssl_certificate_key /etc/nginx/certs/teddycloud/server/teddy-key.pem;
# Require client certificate
ssl_client_certificate /etc/nginx/certs/teddycloud/client/ca.pem;
ssl_verify_client optional_no_ca;
location / {
proxy_pass https://192.168.1.211;
proxy_ssl_certificate /etc/nginx/certs/teddycloud/client/client.pem;
proxy_ssl_certificate_key /etc/nginx/certs/teddycloud/client/private.pem;
proxy_ssl_conf_command Options UnsafeLegacyRenegotiation;
}
}
My commands:
server dir:
openssl rsa -inform DER -in teddy-key.pem -out ttt-teddy-key.pem
openssl rsa -inform DER -in ca-key.pem -out ttt-ca-key.pem
cat teddy-cert.pem ttt-teddy-key.pem ca-root.pem ttt-ca-key.pem > fullchain.pem
client dir:
openssl x509 -inform DER -in ca.der -out ca.pem
openssl x509 -inform DER -in client.der -out client.pem
openssl rsa -inform DER -in private.der -out private.pem