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.

  • 4
    @Blam It's not something you can control on the server. The web browser is going to care. – John Kugelman Jan 13 '14 at 18:26
  • 3
    @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 '14 at 23:42
  • 1
    @JohnKugelman I know it does more. Did you read the question? – Blam Jan 14 '14 at 14:04
  • 1
    @JohnKugelman Yes I am aware that SSL does a lot a stuff. SSL requires a certificate. How do you propose to solve the problem of a certificate that does not expire? – Blam Jan 14 '14 at 15:31
  • 1
    @JohnKugelman Then why do you criticize my comment on how to encrypt without a certificate? – Blam Jan 14 '14 at 15:48

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.

  • Thanks, this is close. Too bad there is the rub with client browsers having to have the cert installed. – Keith Hill Jan 19 '14 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 '14 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 '14 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.

  • 1
    Also, the expiration date of the certificate has become the commodity which CAs charge for. – Marcus Adams Jan 13 '14 at 19:52
  • 2
    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 '14 at 20:50

RFC 5280, Section ("Validity") does answer your question technically exactly.

In short, a certificate with an expiry date of 99991231235959Z (23:59 GMT on 31st of December 9999) does serve your exact requirements, but RFC 5280 also requires that you must be able to revoke that certificate in order to break the certification path (i.e. by revoking the certificate) before this date.

The expiry date is also regarded as a date when the user should review if the technical measures in place still meet the current standards (e.g. if they should upgrade from 1024 bit long modulus to 2048 bit long modulus, or upgrade their server from DES to AES).

For the same reason, commercial CAs do agree not to issue certificates for more of 3 years into the future and do require publicly resolvable DNS names on public IP space; most likely, both of those requirements are blockers to you.

So in the end, there are only two options:

  • become your own Root CA and do issue such certificates automatically. A policy to issue certificates "forever" doesn't meet with the security considerations of browser and OS vendors, so this will ultimately require your users to import your Root CA manually. Advising your users to trust your Root CA is a sensitive operation and may not find that good acceptance among your users. The CA may be using x509 name-restrictions (so issued certificates are only valid for some domain or IP subnet), but everyone with some security in mind will still question if it's a good idea to go that way. In short: this can become very complex, tricky and risky - don't do this.

  • on fabrication or "reset to factory settings", do generate an individual private key on and/or for every device and issue a self-signed certificate with an expiration date of e.g. 10 years into the future (or the special date mentioned above). The documentation needs to ask your users to remove previously installed certificates after "reset to factory settings" and to import that specific certificate in order to avoid the browser warning. Extra karma for explaining to the user why this needs to be done :)

Do mind when you're using the "forever" date, the certificate may still become "less secure" or "invalid". As an example, browsers and operating systems do dictate a minimum keylength or (broken) algorithms to reject and update those requirements accordingly. So right now, 1024 bits may "work", but browsers start displaying connections using less 2048 bits to be "not secure" or as "invalid". And algorithms do break as well to the point where browsers don't put any trust in them anymore. If your self-signed certificate makes use of this, you'll need to update it accordingly.

  • This cert is not Y10K compliant! Ha Ha, like any of us will care about that. – granadaCoder Oct 10 '16 at 19:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy