Feasibility of hosting Teddycloud

Indeed Traefik does support TCP routing as well.
I don’t know if you can mix TLS termination though.

I’ll try to come up with a Traefik example and post it here.

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.

3 posts were split to a new topic: Limit access to box

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.

A post was split to a new topic: Use certificates and nginx

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:

  • ttt-fullchain.pem
    • teddy-cert.pem
    • converted teddy-key.pem (rsa private key; openssl rsa -inform DER -in teddy-key.pem -out ttt-teddy-key.pem)
    • ca-root.pem
    • converted ca-key.pem (rsa private key; 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:

  • ca.pem
    • Issuer: C=DE, ST=NW, L=Duesseldorf, O=Boxine GmbH, CN=Boxine CA
    • C=DE, ST=NW, L=Duesseldorf, O=Boxine GmbH, CN=Boxine CA
	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;
2 Likes

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 :smile:

Hey, unfortunately I have the same problem. Does anyone have an idea?

Had no issue with the “fullchain” in nginx by exactly following what @cfelder explained here.