Signing the certificate of an IP cam

Hey,

I want to provide a certificate for my IP cam.
My environment:

  • A router with an activated Port Forwarding to my IP cam (let’s say https://rtps.example.com:9900 -> 192.168.1.3:443

  • An IP cam (D-Link DCS-5222L) with the internal IP 192.168.1.3

The IP cam provides a Web interface, in which I can generate a certificate request. For this I have to capture some certificate relevant values. After I entered all these values I can download the certificate request:

My first question now is: Which values I have to enter in all these fields, in order they are valid for a Let’s Encrypt certificate?

If I download the certificate request in the next step (Filename: server_csr) what shall I do with this request now? Finally I should have a valid Certificate file, which I can upload (again via Web interface of the IP cam - there is no ssh or telnet access) to the IP cam. But my problem is, that I really don’t have an idea, how can I achieve this. Any help would be nice!

PS: I think, I have do renew this certificate manully all 60 - 90 days in my enviroment, right?

Thanks in advance,

Michael

certbot --csr server_csr -a some_authenticator -d some_domain [...]

Be advised that it will not autorenew before expiration.

You can probably automate the thing yourself sending http requests with curl to upload cert and key, etc etc

Thank you for the fast reply! And the fields in the certificate request can be filled randomly? (except Common name)

Correct. Let’s Encrypt doesn’t use those anyway. Key length might be of interest of course with 2048 bits being the lowest accepted by Let’s Encrypt and 4092 being the highest.

Two things though:

  • I’m wondering: are you going to be the only person using the HTTPS connection? Or are multiple users going to use the stream? If it’s the former: you might want NOT to choose a public certificate authority like Let’s Encrypt. Your hostname will be publicised in the Certificate Logs. Also, with Let’s Encrypt you’ll need to renew your certificate at least every 90 days (every 60 days is the current advice), which might become a hassle, because it needs to be done manually on your cam. If this is the case, you might want to make your own private CA, which is very easily done! If it’s the latter case, perhaps Let’s Encrypt is indeed the best option (do note about the CT logs though).
  • You have your public port 443 mapped to port 9900 of your camera. You also need to map port 80 to a webserver listening and answering for the http-01 challenge if you choose to use that one. This can be a temporary spun up webserver of certbot (if you choose that client) if you don’t have a webserver like Apache or nginx already running. If you choose to use the dns-01 challenge, this of course isn’t needed.
1 Like

Hi, Osiris!
Indeed I am the only person using this connection. That’s why I’ve tried it with a self-signed certificate, but the result was not what I want:

Ok, I know, I can bypass this warning - but in my case I’ve embedded the video of this site in another website and because of this the video was NOT playing there.
If I’ll make my own private CA described in your link, do I also have this warning? Or will the https site will be displayed “as safe” like in the picture in my next post?

The idea about “your own CA” is that you can add the generated root certificate of your own CA to the root store of your browser or operating system. You can make this root CA certificate to have a lifetime of for example 20 years. Then, using that root certificate, you can generate a “leaf” (“end user”) certificate for your camera, which might have, for example, 1 year lifetime. In that case you would only have to renew your certificate once a year, not every 3 months.
And because you’ve added the root certificate to your browser or OS, you won’t get an error.

Thank you very much for the useful information - will try this tomorrow!!

you should probably use a reverse proxy. a webserver that connects to the camera over http and relays everything on https.

do you have a machine that can do that job, on the same network as the camera?

(or elsewhere, but in that case you also need to have your own CA, but only the reverse proxy needs to trust it, so you can have public --trusted https--> reverse proxy --your https--> camera)

Yes, I have a webserver (Raspberry Pi4) in the IP Cam’s network. On this webserver the ‘real’ website is hosted, which embedds the video of the cam.
Webserver (Apache): 192.168.1.20 (externally reachable under http(s)://cctv.example.com). Embedded (at the moment) is the https-stream (MJPG) of the IP cam (https://rtsp.example.com).
These are my first steps regarding hosting a webserver and certificates, so I’ll thank you again for your valuable advices :slight_smile:

Start from here, then: https://httpd.apache.org/docs/2.4/mod/mod_proxy.html

You can also use caddy or nginx, though (it’s probably easier, but one thing at a time)

Well, if everything is on the same network, I would opt for a reverse proxy too! Good idea @9peppe. That way no TLS certificate is needed on the IP cam, as everything is only transmitted over the local network, which I assume is safe.

1 Like

It should be safe enough.

1 Like

Relatively unimportant comment - it was not necessary to black out parts of the CSR shown in the screenshot. A CSR is a public document, if somebody is shown this they only learn from seeing it what is shown above it - the name you want a certificate for, plus a public key which (as the name suggests) is intended to be public. The appliance picks a random Private Key and doesn’t tell anybody, not even you, so this is a very good security practice.

But yes I second people’s recommendation to consider proxying the video feed so as to shield this device from any attacks. It will be lot harder for them to explore attack vectors on the IP Cam if they can’t even connect to it directly.

2 Likes

Something else that I didn’t see emphasized here:

This environment might not be a very good match for a publicly-trusted certificate like those from Let’s Encrypt for other reasons. First, Let’s Encrypt certificates each last for a short time and are meant to be used in an environment where they can be automatically renewed, which would require support on the camera or at least on another device that can control the camera via a software interface. Second, depending on whether you put in rtsp.example.com in order to hide your public domain name, it’s worth noting that Let’s Encrypt can currently only issue a certificate if you have a publicly-visible domain name.

The NAS applicances from Synology have been pretty successful here because they allow customers to register individual subdomains under synology.me, and then Let’s Encrypt can issue certificates directly to the customers for their respective subdomains. Users can also choose to register their own domain names and use those with the NAS instead. For a publicly-trusted certificate, you would need something like one of these paths to be available.

1 Like

Thank you again for your advices - it works now perfectly with the reverse proxy :slight_smile:

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.