Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Is there such a thing as a non-expiring SSL certificate? Our scenario is that we develop and sell embedded devices (think "internet of things"). These devices have little web servers running on them that allow for certain administrative functions (like a Cisco home router allows admin actions). We would like to have good security on these little web servers i.e. not pass clear text passwords. The most straightforward approach is to use SSL to pass the password in an encrypted SSL session. However, these little web servers are not under our control once we sell them to our customers. How do we handle expiring SSL certificates in these devices? Upgrading SSL certs on systems not under our control wouldn't be easy. Is there a better to provide a safe-login experience for this type of device? If the "internet of things" really takes off, I have to believe this is going to become a common issue.

share|improve this question

migrated from stackoverflow.com Feb 3 at 17:02

This question came from our site for professional and enthusiast programmers.

    
You can't tell the web server to not care if the certificate is expired? –  Blam Jan 13 at 18:25
3  
@Blam It's not something you can control on the server. The web browser is going to care. –  John Kugelman Jan 13 at 18:26
    
@NicoleCalinoiu there is not much embedded activity on Security.stackexchange.com. There are no embedded tags at all. –  Keith Hill Jan 13 at 18:42
    
@KeithHill: There's less traffic over there, so less need for really granular tags. There are also quite a few folks who are very knowledgeable about all sorts of security edge cases. YMMV... –  Nicole Calinoiu Jan 13 at 20:26
2  
@Blam No way, absolutely don't do that. Homebrewed security systems are recipes for disaster. SSL provides a lot more security than just protecting passwords in transit. –  John Kugelman Jan 13 at 23:42

2 Answers 2

up vote 2 down vote accepted

Effectively, yes - you could generate your own root certificate (i.e. become your own Certificate Authority) and then sign each SSL certificate CSR with the root key. Then you will be able to set the expiry date way into the future (e.g. use a very optimistic product lifetime estimate) on the SSL certificate installed on each device. The only fly in the ointment is that your root certificate will have to be installed as a trusted root in each client web browser that accesses the admin functions. If this is too complicated for your users, they could simply trust each certificate individually which may be easier. Actually, having thought a bit more about this, each individual certificate would need to be bound to a certain host name or IP address anyway to avoid any other browser warnings (e.g. certificate host name not matching actual host name in browser) so your host name would have to be "hard coded" into the device. As this is not practical, each user would need to click past the browser warning to access the device. The workaround is that you will need to make it so they can update the certificate themselves to completely remove the browser warnings or you could make the device generate its own certificate.

My ZyXel NAS offers the functionality to generate its own and allows the common name to be set for the certificate:

enter image description here

Generating your own certificates will have the same encryption benefits of using public certificate authorities and as the individual devices will have their own private host names anyway, this solution might be more appropriate than using a public CA. Intranet Certificates are available (but are being phased out), but as they require a full domain name or IP address your customers would need to update them themselves on the device.

Please see this article for the full details on how this works.

share|improve this answer
    
Thanks, this is close. Too bad there is the rub with client browsers having to have the cert installed. –  Keith Hill Jan 19 at 1:00
    
So is your plan to install the certificate per device sold, setting the common name to the FQDN each device will have (i.e. giving each device a public domain name)? Otherwise you may get a warning anyway since it appears that intranet SSL certificates are being phased out (answer updated with link). –  SilverlightFox Jan 19 at 13:01
    
We can't dictate an IP address, hostname or a FQDN. The device generated certificate approach sounds interesting. Thanks for the info and the links you've provided - very helpful. –  Keith Hill Jan 19 at 22:34

No, and there are several reasons for it:

  • A certificate contains not only information about the owner, but it contains its public key. The matching private key is only known to the owner of the certificate, and using public key cryptography one could verify, that the endpoint of the SSL connection is really the owner (or at least the one who has the private key). The certificate itself is signed by a certificate agency trusted by the browser (this is all simplified). But, the cryptographic strength of all this stuff depends on the size of the keys and the algorithms used. Increased size makes everything slower, less size makes everything less secure. And because computers get faster and crypto experts only better and finding new ways to crack an algorithm the cryptographic protection of the certificate gets weaker with time. Therefore each certificate needs to expire before the protection gets to weak.

  • A certificate might get compromised, e.g. some bad guy or agency might get the private key and thus identify itself as the owner or decrypt all traffic. In this case the certificate gets revoked and the revocation info are made public accessable. If the certificate would never expire these information would need to be kept forever and the storage needed and the time to check a certificate for revocation would grow. That's way cheaper end-user certificates have a shorter expiration time then more expensive certificates, because cheaply minded end-users probably don't protect their private key as well, so it's good that their revocations can be thrown away after the expiration date.

share|improve this answer
1  
Also, the expiration date of the certificate has become the commodity which CAs charge for. –  Marcus Adams Jan 13 at 19:52
    
Thanks. That is what I figured. Most folks here are probably used to only dealing with web servers they have complete control over. If you had think about the problem space of a web browser in a product you sell (refrigerator, WiFi garage door opener, Wifi sprinkler system, WiFi router) - how would you ensure admin login credentials are not passed plain text to the device? –  Keith Hill Jan 14 at 20:50

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.