Classes, also known as DataGroups, are name->value pairs that will allow you to easily retrieve the data later in the iRule. This could be done in any manner, really, but the most efficient both from a resource and management perspective is to use a class. Now on to the geekery:įirst things first, you’ll need to create a mapping of which servernames correlate to which certs (client SSL profiles in LTM’s case). Because Joel Moses, the shrewd mind and DevCentral MVP behind this example has already done a solid write up I’ll quote liberally from his fine work and add some additional context where fitting. Lucky for us, one of the many bright minds in the DevCentral community has whipped up an iRule to show how you can finally tackle this challenge head on. Now all we need is some logic to make this happen. We should be able to pull out this information and choose an appropriate SSL profile now, with a cert that corresponds to the servername value that was sent. Known to us mortals as "Server Name Indication" or SNI (hence the title), this functionality is paramount for a device like the LTM that can regularly benefit from hosting multiple certs on a single IP. Finally we have what we’ve been looking for, a way to add contextual server info during the handshake, thereby allowing us to say “cert x is for domain x” and “cert y is for domain y”. The TLS protocol has somewhat recently provided the ability to pass a “desired servername” as a value in the originating SSL handshake. We’d like to help, but we just really can’t. You can’t do anything with the connection until the handshake is established and decryption is done on the LTM. One VIP, one cert, that’s how it’s always been. The answer has always historically been “I’m sorry, you can’t.”. An age old question that we’ve seen time and time again in the iRules forums here on DevCentral is “How can I use iRules to manage multiple SSL certs on one VIP"?”.
0 kommentar(er)
