The current SSL capabilities included in FM product family provide the essential security capability but do not include features commonly used by developers, institutions, and hosting providers. Enhancements in this area would improve the acceptance of the FM platform into larger and security conscious organizations.
The base case is ok, where someone runs FMS on a dedicated box with no other IT infrastructure and doesn't mind using on FMI's hand picked certificate issuers. However, there isn't much room to deviate from this pattern.
I really don't need every feature of the OpenSSL toolkit exposed, but there are some options that are very widely used and have straight forward justifications.
- Wildcard certificates (this one is obvious, yes?)
- Allow more certificate authorities (FM has 7, OS X: 198, Firefox: >200)
- Allow custom CAs (for development or intranet deployments)
- Support certificate chains
- Easily import keys and certificates that have been created externally (openssl genrsa) Updated 2016-01-11, already available.
Client Side Improvements
Utilize Operating System's Certificate Authorities
- In OS X and iOS, Apple provides libraries that verify trust using the Keychain "System Roots". All the Apple applications use this. Chrome uses this. Windows has similar standard "Certificate Stores". Delegation in this area to the OS should improve both functionality and security.
- Private networks can safely use self-signed certificates (when done properly)
- Institutions can that run their own CA can deploy additional roots on OS X, Windows, and iOS.
- If supported, mid-sized shops can save money and avoid headaches by using Wildcard certificates.
Server Side Improvements
Expose a few more OpenSSL configuration directives (for all FMS connections, not just http)
- SSLCertificateFile (the signed certificate, currently bundled into serverCustom.pem)
- SSLCertificateKeyFile (the private key, currently bundled into serverCustom.pem)
- SSLCertificateChainFile (many CA sing using intermediates, signing certs, etc. Fine if you want to support intermediates in the certificate file instead)
High Security, Regulated Industries, Future Compromised Ciphers
This is also important, but won't garner as much support from the community... As times change some ciphers need to be phased out. This would be pretty easy to do without requiring a complete patch release & install. Some institutions might only want to enable the strongest ciphers, or might want to require a minimum cipher key size. We also need to be able to respond easily when new industry requirements come out, such as PCI - Migrating from SSL.