SSL Certificate

[djkprojects]

Hello,

I want to start using SSL cert to secure my QNAP server so I could only access the QTS via https, SFTP instead of FTP etc. but I'm a bit confused as to what certificate I need for what. When I go to Control Panel --> Security --> Certificate & private Key it states that I already have a cert (not sure if that came as part of the bundle when buying my server):

Screen Shot 2017-08-05 at 14.55.24.png

Then there is some mention of SSL for myQNapCloud. it's very confusing for me.

Can someone please advise ? Thanks

[djkprojects]

nobody knows?

[schumaku]

There is nothing that stops you from using https, ftpes (this is the secured ftp ... sftp is ssh...) - regardless of using the factory default certificate (with a public key probably shared by many similar NAS), with a self-signed certificate, ...

Beyond, it depends what you have (ie, an own domain, own or SAS based DNS), a well known DDNS name of a DDNS service you need to retain, ...

[djkprojects]

There is nothing that stops you from using https, ftpes (this is the secured ftp ... sftp is ssh...) - regardless of using the factory default certificate (with a public key probably shared by many similar NAS), with a self-signed certificate, ...

Beyond, it depends what you have (ie, an own domain, own or SAS based DNS), a well known DDNS name of a DDNS service you need to retain, ...

Hi schumaku,

Yes, I'm aware of the self cigned certificate option however my question is more around which cert I need for what e.g. what is the certificate I have on the screen in my first post for ?

How will self signed cert work with CloudLink/DDNS when connecting to my NAS remotely ? Won't the handshake fail ?

Thanks

[schumaku]

There is only once user installable certificate. On a new installed system, there is a factory default certificate in place. The certificate is used for https, ssh/sftp, ftpes, ... for both QTS and the Web Server Service.

How will self signed cert work with CloudLink/DDNS when connecting to my NAS remotely ?

CloudLink is using a complete different technology, the user installable certificate is not involved. The very same certificate is used regardless from where the NAS is accessed directly.

Won't the handshake fail ?

The handshake won't fail, the session can be established. Of course, ie. a browser won't show an "light" green indication when the name does not match, when a elf-signed certificate is used (except when imported to and forced "trusted" the browser of course).

[djkprojects]

Hi schumaku,

Thanks for your reply.

Do I understand correctly then that the cert that came with the NAS (the one on the screen I shared) is for accessing NAS SFTP, SSH and the Web server directly (if enabled) and the Cert QNap are selling is for accessing NAS via CloudLink ?

Thanks

[djkprojects]

Hello,

Could someone please advise if my understanding of the Certs is correct? Just want to make sure that I'm not making a mistake when purchasing one from QNap

Thanks

[schumaku]

Then buying a certificate, it depends on what name or URL you want to access the NAS:

The QNAP Certificate is signed for using [yournasname].myqnapcloud.com (this is unrelated to CloudLink at all).

Other generic certificate providers allow providing whatever.domain.name ... this requires you have you own domain name, a DNS server in the Internet serving the name to IP address (A records for IPv4 address and AAAA records for IPv6 address) and in case the Internet connection does provide a dynamic, not fix assigned IPv4 (and/or IPV6 prefix) the update mechanism must be in place, too.

Let's Encrypt does allow "any" names registered, no need to proof the domain ownership, just that the server is owned/managed by you and holding the Let's Encrypt code to validate. As this was and is massively abused, many bigger businesses to no longer trusting in this provider - they force any validation to failed.

Last but not least - only one certificate can be installed, its used for all services.

Unless you need to show a higher trust to the users accessing your NAS, you can still keep operating it on a self-signed certificate.

[djkprojects]

Then buying a certificate, it depends on what name or URL you want to access the NAS:

The QNAP Certificate is signed for using [yournasname].myqnapcloud.com (this is unrelated to CloudLink at all).

Other generic certificate providers allow providing whatever.domain.name ... this requires you have you own domain name, a DNS server in the Internet serving the name to IP address (A records for IPv4 address and AAAA records for IPv6 address) and in case the Internet connection does provide a dynamic, not fix assigned IPv4 (and/or IPV6 prefix) the update mechanism must be in place, too.

Let's Encrypt does allow "any" names registered, no need to proof the domain ownership, just that the server is owned/managed by you and holding the Let's Encrypt code to validate. As this was and is massively abused, many bigger businesses to no longer trusting in this provider - they force any validation to failed.

Last but not least - only one certificate can be installed, its used for all services.

Unless you need to show a higher trust to the users accessing your NAS, you can still keep operating it on a self-signed certificate.

I'm not sure I follow. If [username].myqnapcloud.com has nothing to do with Cloudlink then how does this subdomain get resolved to my home network public IP. Is it not what CloudLink + DDNS are for?

I'm not looking for my own domain that would be pointing to my public IP, this I could do with any domain provider, in fact I own a few domains already.

I'm going to explore Let's Encrypt which is now available directly from QTS.

Thanks


Sent from my iPhone using Tapatalk

[schumaku]

I'm not sure I follow. If [username].myqnapcloud.com has nothing to do with Cloudlink then how does this subdomain get resolved to my home network public IP. Is it not what CloudLink + DDNS are for?

No, nothing ... completely unrelated: CloudLink does not need any DDNS, any port forwarding, .... CloudLink is a connection initialised by the NAS to a QNAP cloud infrastructure. And you access it via the http://www.myqnapcloud.com Web server on the QNAP cloud infrastructure, the CloudLink enabled Apps do the very same. And for the QNAP http://www.myqnapcloud.com infrastructure there are valid certificates in place.

When establishing a direct connection to the DDNS name like [whatever].myqnapcloud.com over a pot forwarding if a NAT router is in place it's a different story - now you need a certificate signed for [whatever].myqnapcloud.com - issued by the QNAP offering, or by a CA not requiring the same trust levels, for example Let's Encrypt.

Start with some reading on myQNAPcloud and CloudLinkk -> https://support.myqnapcloud.com/features?lang=en

[jameshenderson]

I'm going to explore Let's Encrypt which is now available directly from QTS.

How did it go? ...I didn't want to download a Lets Encrypt certificate without knowing that the NAS can auto-renew it every 90 days.

[chitownbob]

IF I may ** in....
It dd not go well for me.

A little background: My home, family and QNAP are back in Chicago.
I moved to North Carolina for a job opportunity.
I brought my PC with me. My PC and three others had drives mapped to QNAP TS-453a in Chicago.
Used Qnap's Cloud Connect to connect back to NAS in Chicago, rewrote mapping script to go to shares on Cloud.
Also set up FTP server on PC so I could perform nightly backups from Android to public photo folder, then QSYNC these to NAS.
Everyone else's ITUNEs music is on NAS. Chicago connection too slow. Moved all my music to local PC.

End of background.

I craved a little move security. So I tried SSL using Qnap's LetsEncrpt. A couple of clicks and done.
I close my browser to test, and can no longer connect to NAS via QNAP Connect.
Back in Chicago. Local Backups to mapped drives run just fine. Data still accessible.
Qfinder still finds my NAS at 192.168.1.3
QSYNC detects my NAS at 192.168.1.3 but does not Sync
Also I can no longer access NAS via https:\\192.168.1.3 or http:\\192.168.1.3
I am looking for a way to back out or repair the SSL changes I made.