Use certificates and nginx

Software TeddyCloud
1

Hi,

i am trying to use a nginx setup. tc and nginx will be running in two containers on same host. both have their own Ip address via macvlan.

Its my first time using nginx, just trying to figure out your configs.

I am a little confused on the certificates you are using. I don’t recognise the names you use for certs and keys.
The certs I have are

ca.der  ca-key.pem  ca-root.pem  teddy-cert.pem  teddy-key.pem

for server and

ca.der  client.der  private.der

for client.

did you just rename yours?

Also, how can I get the fingerprints?

Thanks!

2

Those certificates are for teddyCloud only.
What do you want to achieve with nginx and the certificates? There is no need for a reverse proxy between teddyCloud and the boxes. As this is complicated to use, we do not recommend that in our docs.

3

I want to make Teddycloud available on my public IP to Access it from anywhere, but do not want to expose 443, so would like Nginx to reroute…

4

Ok to rephrase this, of course I will have to expose 443, but I want nginx to secure the connection by using mTLS as described in

Feasibility of hosting Teddycloud

My question is:
In the example nginx configs that are provided in that thread, different certificates and keys are used.
Do they differ from the certificates provided during teddycloud initial startup?
If so, how were they generated?
How were the keys generated?

Im referring to:

Thanks for any help!

5

Anyone has any help?

I managed to setup a nginx entity.
I created the fullchain.pem by cat’ing teddy-cert.pem and ca-root.pem
Still not sure about the ssl_certificate_key. using teddy-key.pem did not work, hat to convert it with

openssl rsa -in /etc/nginx/certs/server/teddy-key.pem -out /etc/nginx/certs/server/teddy-key-converted.pem

my config looks like this:

http {
server {
listen 7443 ssl;
listen [::]:7443;
server_name _;

ssl_protocols SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ALL:!aNULL;

# Server's certificate and private key
ssl_certificate /etc/nginx/certs/server/fullchain.pem;
ssl_certificate_key /etc/nginx/certs/server/teddy-key-converted.pem;

# Require client certificate
ssl_client_certificate /etc/nginx/certs/client/ca.pem;
ssl_verify_client optional_no_ca;

location / {
        proxy_pass https://teddycloud:443; # Forward to your cloud service
        proxy_ssl_certificate /etc/nginx/certs/client/client.pem;
        proxy_ssl_certificate_key /etc/nginx/certs/client/private.pem;
    proxy_ssl_conf_command Options UnsafeLegacyRenegotiation;

}

}

I am able to connect to teddycloud with curl or openssl_client using the client certs and ca-root.pem.
but if I try it with the box, I get a failed handshake “wrong signature type”.

Thanks!

6

Seems like nginx is providing its list of approved signature algorithms in Certificate Request message. The box then sends the Certificate Verify message with signature algorithm 0x0201 rsa_pkcs1_sha1. That one is not in the list of approved signature algorithms, so the server throws an error.

I can’t get nginx to append 0x0201 to the list of approved signature algorithms…

7

The CC3200 uses deprecated ciphers, that are not supported by current openSSL versions anymore. This is another reason, why I would not recommend using nginx to terminate the TLS connection. TLS Paththrough would solve this problem.

Why do you want this? Do you have multiple hosts behind that IP/Port?

8

I was able to get it working using an older version of nginx and ssl_ciphers ‘HIGH:!aNULL:!MD5@SECLEVEL=1’;

Just realised it also works with nginx_latest and ‘HIGH:!aNULL:!MD5@SECLEVEL=0’;

is it a a bad idea to use an old version or use small sec level? How is this done in boxine? they wouldn’t want an old insecure SHA1…

exactly, have different applications running that require https on 443.

9

This degrades the security of TLS. If it is only used for the Toniebox, the impact is quite low.
The problem is the cc3200, that doesn’t support newer ciphers.

For that reason, I would just pass through TLS connections without terminating it, if a request comes without SNI comes.