Due to the deprecation of SHA-1 based SSL certificates, a few Certificate Authorities no longer issue SSL certs with SHA-1 root and are instead issuing SSL certs with SHA-2 root.

This is problematic for nearly all IronKey devices in the field.  Almost none will trust the SHA-2 root CAs.


If you're in a hurry to replace your Enterprise Server SSL certificate, contact one of the Certificate Authorities below and ask for "a SHA-2 SSL cert issued by SHA-1 root":


Certificate Authorities issuing from trusted SHA-1 root as of Aug 2016:

----------------------------------------------------------------------

Comodo.com     - no planned SHA-1 root sunset

Entrust.net    - no planned SHA-1 root sunset

GeoTrust.com   - no planned SHA-1 root sunset

GlobalSign.com - no planned SHA-1 root sunset

Sonera.com     - only issues to EU Nordic countries

Thawte.com     - no planned SHA-1 root sunset

VeriSign.com   - no planned SHA-1 root sunset


GoDaddy no longer issues SSL certs from a SHA-1 root.


What follows is a brief explanation of certificates and encryption hashes and the impact on IronKey devices:


All SSL certificates exist in a certificate chain of parent/child.  The first parent is the "root Certificate Authority (CA)" and is self-signed.


The parent of each child is called the "issuer".  There can be multiple parents, called "intermediate", in the chain.  The last certificate is the "end-entity" SSL certificate and is the SSL certificate deployed on the web server or Enterprise Server.


Each certificate has a (self) subject key identifier and (parent) authority key identifier.  This establishes the parent-child chain.


Certificate chain example:

root CA

subject key identifier:  3a 9a 85 07 10 67 28 b6 ef f6 bd 05 41 6e 20 c1 94 da 0f de

   intermediate1 CA

   authority key identifier:  3a 9a 85 07 10 67 28 b6 ef f6 bd 05 41 6e 20 c1 94 da 0f de

   subject key identifier:    40 c2 bd 27 8e cc 34 83 30 a2 33 d7 fb 6c b3 f0 b4 2c 80 ce

      intermediate2 CA

      ...

         intermediateN CA

            end-entity SSL certificate

            authority key identifier: 40 c2 bd 27 8e cc 34 83 30 a2 33 d7 fb 6c b3 f0 b4 2c 80 ce

            subject key identifier:   ee 76 a5 f2 22 9f 70 3d 11 77 57 0c e1 18 cc f5 c9 7f 40 f2


Anyone can create a Certificate Authority (CA) and begin issuing certificates.  However, very few CAs are trusted.  IronKey devices have a file of trusted CA certificates in the IronKey Unlocker partition called \Common\certs\iksiteca.crt.  This list is referred to as a Trust Store.  Web browsers, such as Chrome, and Firefox, have similar Trust Stores.


SHA-1 and SHA-2 are two different cryptographic hash methods for creating unique certificates.  Older hash methods, like MD5, exist but have fallen out of use due to publicly understood cryptographic attacks on commodity hardware.


The SHA-1 hash output is 160 bits, but is widely considered susceptible to cryptographic attacks on very large compute platforms and has been removed from use for end-entity SSL certificates.


When someone refers to "SHA-2", they are referring to the entire family of SHA-2 hash functions with hash output that are 224, 256, 384 or 512 bits, denoted as SHA-224, SHA-256, SHA-384, SHA-512/224, and SHA-512/256.


The SSL certificate hashing method is the basis for the SSL traffic encryption.  Put simply, the more bits in the hash, the stronger the encryption.


Notably, the root CA or intermediate CA certificate hash method has no bearing on the end-entity SSL certificate encryption strength.  For example, a SHA-256 SSL certificate with a SHA-1 root CA parent will encrypt traffic with SHA-256 strength.


IronKey devices validate all SSL connections to IronKey EMS against the on-board Trust Store.  The device verifies the IronKey EMS SSL certificate chain to find any trusted certificate in the chain (end-entity, intermediates, or root).  The chain verification is done by checking each certificate's subject key identifier and authority key identifier to verify a complete root-intermediate(s)-end-entity certificate chain.


With the deprecation of SHA-1 based SSL certificates, a few Certificate Authorities (ex: GoDaddy) no longer issue SSL certs with SHA-1 root and are instead issuing SSL certs with SHA-2 root.  This is problematic for nearly all IronKey devices in the field.  Almost none will trust the SHA-2 root CAs.


SHA-2 SSL certificate encryption support:

- ALL versions of all IronKey devices (S100, S200, D200, S250, D250, S1000, W300, W500, W700, H300, H350).


SHA-1 root* CA trust:

- ALL versions of all IronKey devices (S100, S200, D200, S250, D250, S1000, W300, W500, W700, H300, H350).


SHA-2 root** CA trust:

- S250 v3.5.0.0 and higher

- D250 v3.5.0.0 and higher

- S1000 v5.0.1.0 and higher

- W500 v4.3.0.1 and higher (excluding 4.3.1.0)

- W700 v4.3.0.1 and higher (excluding 4.3.1.0)

- H300 v5.2.0.0 and higher

- H350 v5.2.0.0 and higher


(*) - Supported Certificate Authority:  Aba.com, AddTrust, Baltimore, BeTrusted, Comodo, DST, Entrust.net, GeoTrust, GlobalSign, GoDaddy, GTE, RSA Security Inc., Sonera, TC TrustCenter, Thawte, Valicert, VeriSign, Visa


(**) - Supported Certificate Authority:  Aba.com, AddTrust, Baltimore, BeTrusted, Comodo, DigiCert, DST, Entrust.net, GeoTrust, GlobalSign, GoDaddy, GTE, RSA Security Inc., Sonera, TC TrustCenter, Thawte, Valicert, VeriSign, Visa


Example:  FBI runs an IronKey EMS On-Prem server reachable at https://ironkey.fbi.gov and has 1,000 IronKey S250 v3.4.3.3 devices.  The "ironkey.fbi.gov" SSL cert is currently issued by a SHA-1 root CA.  SHA-1 root issued certificates no longer meet Federal Security Policy guidelines, so FBI purchases a new SSL certificate issued by a SHA-2 root, and updates their On-Prem SSL certificate.  Their IronKey devices can no longer connect to the FBI OnPrem since none trust the SHA2 root CA that issued their new SSL certificate.  FBI must upgrade all their S250 devices to v3.5.0.0 or higher.


POSSIBLE WORKAROUND FOR LEGACY DEVICES:  The device CA trust store file \Common\certs\iksiteca.crt can be *overwritten* with an updated iksiteca.crt every time the client operating system mounts the IronKey device.