As of version 16.0 build 1690 and version 12.0.1 build 3994, SQL Anywhere uses OpenSSL to provide strong encryption routines. What impact will this change have for SQL Anywhere customers using strong encryption?
asked 08 Nov '13, 14:21
In short, unless you are using the SQL Anywhere FIPS module, you will likely not notice any changes. Existing encrypted databases will continue to work, data encrypted using the
There are a couple of behaviour changes that apply:
If you are using a self-signed certificate in your identity file, the certificate must have the Certificate Signing attribute set. You can use the viewcert utility to see if that attribute is set (under Key Usage). If it is not set, then you must generate a new certificate that has this attribute set.
If you are using client-side certificates with MobiLink, the certificate now requires the Digital Signature attribute to be set. As above, you can use the viewcert utility to see if that attribute is set but if not, you must generate a new certificate.
With Certicom, a client could trust any certificate in the signing chain and the TLS handshake would succeed. With OpenSSL, the client must trust the root certificate in the chain.
However, if you are using FIPS, there are more changes. These are listed and described below.
If your database or MobiLink server is accepting TLS or HTTPS connections with FIPS, or your MobiLink server is using end-to-end encryption with FIPS, the identity file you used before must be modified before it can be used with new software. The Certicom FIPS module only accepted identity files containing private keys that were encrypted with the 3DES algorithm. However, OpenSSL will not accept such identity files in FIPS mode, so the private key must be re-encrypted with AES. To do this, you can use the viewcert utility. You need to specify the existing identity file, its password, the new identify file you want to create, and the new password. The new password can be the same as the old one if you want. Use the following command:
viewcert -p -o new-file-name -op new-password -ip old-password old-file-name
Note that only the identity file needs to be modified - the trusted certificate files on client machines will still work as-is.
If it seems odd to be using viewcert to change something, realize that you're not actually changing anything. You are displaying an existing certificate in a different format.
Note that the new identity file you create cannot be used with older servers (i.e. those that use Certicom software) since the Certicom FIPS module does not support private keys encrypted with AES.
The createcert and viewcert utilities
These utilities now default to using AES to encrypt private keys. AES is a more secure algorithm than 3DES, and as previously mentioned, the OpenSSL FIPS module does not support 3DES. However, the Certicom FIPS module does not support AES, so it is not possible to create an identity file that can be used with both. If you need to use a new (OpenSSL) version of createcert to create a certificate that can be used by an old (Certicom) version of the server, you will need to specify the
Similarly, if you're using
If you are deploying SQL Anywhere as part of your application and you are including the FIPS module, there are some changes in the list of files you must include. The DLLs and shared objects that were required before were:
The sbgse2 library has been removed and replaced with two different libraries. On Windows, a Microsoft runtime library is also required. The files now required are:
There are some deployment changes for MobiLink as well. Depending on whether you are using FIPS or end-to-end encryption, there are three sets of instructions below.
Using non-FIPS TLS/SSL (including HTTPS) and client-side certificates
Using FIPS, TLS/SSL (including HTTPS) and client-side certificates
These steps update the client identity certificates twice if the Digital Signature attribute is missing from client-side identity certificates. This procedure can make the update less disruptive because synchronizations can continue without having to coordinate the client-side and server-side updates to occur at the same time.
Using FIPS and end-to-end encryption