Can Let's Encrypt be used to sign self-made certificates?

Server
1

Hello!

I absolutely love Let’s Encrypt, but this is my first post here and although I’ve read pages and pages, I am no expert on certificates and SSL, and I find little information on my actual usecase. I am using Let’s Encrypt on my company website and file sharing system already, and have set this up with no issues.

This enquiry however, evolves around my occupation: I install Building Management Systems that offer an option to incorporate HTTPS and other encrypted protocols to enhance security. Although most installers doesn’t bother with this as they find it difficult and unneccesary, I obviously do since I’m posting here.

The encryption works though self-generated, self-signed certificates, so although they greatly enhance security, they are not very userfriendly, since users are presented with (many) warnings about untrusted certificates (the application is running on JAVA).

Some installations will be hosted at the clients sites, either directly in a controller or in an on-site server. Others will be hosted by me using a VPS in a data center. Every device (server, controller, VPS,…) will have it’s own certificate, and these certificates are signed by my own root or intermediate certificate.

What I’m thinking is if I can use Let’s Encrypt to sign my Root Certificate (as a service running on my hosting server), and thus achieve that all my certificates (even on controller level) are trusted by browsers, but obviously not verified like a CA?

I haven’t checked yet, if this usecase is actually permitted for in the license agreement, but providing it is - is it technically possible? And if so, how would I go about setting it up, in outlines?

Kindly,
Nicolai

2

Let's Encrypt only signs end leaf certificates. I.e., the chain of trust ends there. You can not use Let's Encrypt certificates again for signing stuff down the road.

Also, verification and trust go hand-in-hand. How would you expect a browser to trust a certificate, if it cannot verify it up to a trusted CA?

1 Like
3

[quote="Osiris, post:2, topic:29719"]
Let's Encrypt only signs end leaf certificates. I.e., the chain of trust ends there. You can not use Let's Encrypt certificates again for signing stuff down the road.[/quote]

Thank you, this answers my question. Obviously not the answer I was hoping for, though. :slight_smile: I'm clearly overlooking something though, as this is a fairly common scenario for e.g. IoT. Just wish I knew what.

It was probably a poor choice of words. I'm referring to the verification of the certificate holder, i.e. domain verification, organisation verification and extended verification. Let's Encrypt is a domain verification, which goes some way, but doesn't really verify much other than your control over a DNS A record and the target of said record.

What I meant by it is, that I obviously cannot use extended verification or organisation verification on building control systems, as that would require an individual CA signing for each site. But domain verification like with Let's Encrypt would be realistic.

4

Ah.. Well, if you want publically recognised certificates, even if you would find some CA to issue you a certificate with end leaf certificate signing capabilities, you would need to adhere to the CAB Forum Baseline Requirements. And therefore can't just go and issue certificates without verifying the hostnames.

If you need to issue certificates not conforming to the Baseline Requirements, the only option would be to set up your own CA. But those certificates wouldn't be trusted in browsers, unless you install your root certificate into those browsers/systems. Which would only be a viable option if you have control over the clients.

5

[quote="Osiris, post:4, topic:29719"]
Ah.. Well, if you want publically recognised certificates, even if you would find some CA to issue you a certificate with end leaf certificate signing capabilities, you would need to adhere to the CAB Forum Baseline Requirements. And therefore can't just go and issue certificates without verifying the hostnames.[/quote]

This makes alot of sense, however simple it may seem I didn't actually consider the rather obvious concern with omitting host verification.

This is how it works currently - I add each certificate to the trust store of the other controllers, and add a security excemption to accept my certificate in the browser of the client machine. Mostly these systems are accessed from fairly few end-points (typically no more than 3), but there's a shift in that tendency.

I definitely do not need more client administration, though. The current solution runs on JAVA through browser plug-ins, and is only now moving to WebStart JAVA. I'm moving towards an HTML5 solution for this very reason.

I can't help but feel there should be a solution to this, that I am simply overlooking. Take an example like Nest - you can access the thermostat locally (obviously), and remotely through and app and a website. I would very much hope and assume that the communication is encrypted, not only user to website but also website to device.

For the same reason, I've contacted the manufactor and vendor with this concern, as I feel they're in an ideal position to deal with this since they essentially can verify my identity, can verify the product identity and the intended installation site, only needing to do a domain verification after installation. But they don't feel like implementing a hostname verification procedure or bearing the expenses to upkeep one CA signed root certificate.

This type of usecase exists all over the place though, with countless implementations. So surely something is available to overcome this issue without control over client environment and without throwing warnings left and right, but sadly I don't know what that solution would be.

6

Nest obviously controls the clients: they manufacture the Nest devices themselves, including the firmware. Thus, they can easily include the Nest Private Root Certificate Authority root certificate into the Nest products.

(Nest uses a intermediate certificate called Private Server Certificate Authority signed by the foramentioned root certificate with an end leaf certificate for *.devices.nest.com)

But for some reason I'm doubting your situation is not as simple as Nest...

7

There’s a pretty good blog post on how Plex implemented HTTPS for a similar use-case, which might provide some inspiration. acme-dns might be a good building block for a similar solution using Let’s Encrypt.

8

That depends if there's some mechanism in HTTPS (which I assume there is), to protect users from a server with a trusted HTTPS connection that displays content that is from another HTTPS connection but from an untrusted source? So not the typical "HTTP content inside HTTPS" warning, but rather "HTTPS from elsewhere".

Like so:
User ====HTTPS (signed)====> My Server* ====HTTPS (unsigned)====> Control Unit

*) Server hosting a certificate using Let's Encrypt for visitors connection, while also having certificates of my control units added to it's trusted certificates.

I wonder if this would be possible without warnings to users? And if it would be considered a good solution, that's stable long-term - i.e. not exploiting some obvious bug that is simply waiting to be fixed.

Thanks! That is really useful.

I think it's overshot in terms of the current issue, as I'm not likely to get a CA to develop something similar for me, with my (compared to Plex) much smaller implementation. But especially the DynDNS trick is quite useful for another project I have in development for the same market, in which I'll likely need a small computer (i.e. a Pi or Arduino) present in the control cabinet anyways. (I don't have firmware access to controllers, can only input one scripting language and only use sanctioned functions). I will definitely be keeping Plex' implementation in mind then, so thank you so much!

9

The user only deals with the HTTPS connection to your "Server" if the connection is actually terminated at the server (i.e., not just routed forwards into your network like NAT et cetera). Everything the server does to serve content to the user is irrelevant from the users perspective.

So you could set up your own "private" CA indeed. You'd put the root certificate into the trust store of your "central" Server and use end leaf certificates (possibly using an intermediate certificate for security reasons) for the Control Units.

10

Excellent. This server would not be forwarding traffic, I have a separate VPS for servicing and monitoring (VPN and supervisory tools) for security reasons. In order to provide redundancy and security, clients will not be granted any access through this server.

It should function then, since the visualization software subscribes to data points in the controllers through it's behind-the-scenes framework, using a transmission protocol like DSA. When the data point is actually displayed to the user, this happens through the use of HTML5 and CSS for layout and formatting, and the source (the data point value) is essentially sent to the browser like any other text element would be. If it's a graphical representation, it will simply choose the correct image (e.g. fan running or stopped) based on the value, again behind the scenes, and simply output the result to the browser - much like how a PHP script could function.

Based on your explaination, this concept would work then, and my only quarrel would be with those clients, who opt for a self-hosted/on-site server, where the certificate would simply remain unsigned. I think it will be fair to say, that if the client maintains the server, they are also responsible for providing their own certificates if they so desire. And in any case, the self-signed certificates I make will enable encryption and allow for a non-verified identification.

This is definitely the way to go. I've marked this latest post of yours as the solution instead of the previous one, as it answers exactly the question I meant to ask the first time. :slight_smile: Thank you so very, very much. I really appreciate it! :slight_smile:

11

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