If you are a regular reader of our latest series, Introduction to Nimble OS 2.1, you've already discovered some of the really nice functionality that is ready and waiting within the latest 2.1 release. In this latest blog of the series, I am going to delve a little deeper into one of the background changes that you'll see with 2.1 with regards to Self Generating WebUI Certificates.
The more eagle eyed customers may have noticed that prior to 2.1, our certificate had a very odd Certificate Authority. I know this has been the topic of conversation on at least one Nimble:Connect thread. In the past, reviewing the certificate shows the Certificate Authority to belong to a strange organisation 'jetty.mortbay.org':
Picture: Certificate from 2.0.x Nimble array
This certificate authority was issued by the vendor (mortbay) from one of the components we use for our java based services implementation (jetty). Despite being rather obscure this presented a couple of real challenges. Firstly, there was no real effective authentication as this certificate was the same for each and every Nimble array (as it is identical) so a browser couldn't be sure the certificate supplied was coming from a trusted Nimble array. Secondly, the certificate was generated using an older deprecated encryption algorithm (MD5, 1024bit RSA keys), which are now deemed to be less secure in comparison with today's algorithms. These two issues were often highlighted when customers performed security scans against a Nimble device as areas for improvement. Note: in the past customers could have generated their own certificate and installed that to replace the jetty.mortbay.org certificate with Support assistance.
In 2.1, we solved this problem by dynamically generating unique RSA keys and certificates for every array, based on the Serial Number, Array name and IP Address. This allows the certificate to contain identity information so a browser can tie that certificate to each specific individual array.
So after you upgrade to 2.1 the array will automatically create a new unique certificate authority (CA Common Name) based on <Serial No>-CA - this should never need to change.
The array also generates a host RSA key and uses the CA key to sign the certificate - the identity information that is contained in that certificate includes:
- Fully-qualified array name as the common name
- Fully-qualified group name as a DNS name in the Subject Alternate Name
- Management and Discovery IP Addresses in the Subject Alternate Name
The common name is what is normally used by the browser to verify that it's talking to the host that it thinks it's talking to; The Subject Alternate Name is similar to an alias (which is important when we consider a Group can contain 1-4 arrays).
This can be seen, if we review the certificate of an array running 2.1.x:
Picture: Certificate from 2.1.x Nimble array
This new certificate is automatically installed once the array is upgraded to 2.1.x.
Note: For customers that have installed their own certificate in the past, with help from Support, their certificates will remain and not migrated to this new model.
So what happens if I change the Group Name or IP Address ?
All of these identifies are configurable on an array (Groupname, Arrayname, IP Addresses). So if any one of these are changed then Nimble OS will automatically regenerate the appropriate keys and certificate to reflect the changes made to the Array/Group.
Gotcha: It's best practice that if a new certificate has been created then the controller should be failed over to the Standby in order for that process to fully complete. (this currently is a manual step) and obviously is non-disruptive similar to a software upgrade.
So when you upgrade, when you point your browser at the Group you will receive the usual Untrusted Connection warning (here's mine with Safari Browser):
Click on Show Certificate
Then view the certificate and if your happy with it - add it to your Trusted Certificates (here I am stating Always Trust this particular certificate from my array):
After that you will no longer be prompted that the array is an Untrusted Source and examining the Certificate will show it as trusted from the identified host:
So as you can see unfortunately no new toys to play with in today's blog but I thought it would be interesting to show you some of the changes under the covers.
Tomorrow Bill Borsari, will be taking us through another new feature VLAN Tagging. As ever please feel free to ask questions below....