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 encrypt() function before the change can be decrypted using decrypt() after the change, and clients can connect to servers using TLS even if they are using different versions of the software.

There are a couple of behaviour changes that apply:

Certificate attributes

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.

Trusted certificates

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.

FIPS changes

However, if you are using FIPS, there are more changes. These are listed and described below.

Identity Files

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 -3des switch so that the key is encrypted using 3DES.

Similarly, if you're using viewcert -p to view a certificate in PEM format, you must use the -3des switch to encrypt the private key with 3DES rather than the default AES.

Deployment

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:

• dbfips16.dll (Windows)
• sbgse2.dll (Windows)
• libdbfips16_r.so (Linux)
• libsbgse2.so (Linux)

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:

• dbfips16.dll (Windows)
• libeay32.dll (Windows)
• ssleay32.dll (Windows)
• msvcr100.dll (64-bit Windows)
• msvcr90.dll (32-bit Windows)
• libdbfips16_r.so (Linux)
• libcrypto.so (Linux)
• libssl.so (Linux)

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

1. If your client-side identity certificates do not have the Digital Signature attribute set and the client connects directly to the MobiLink server, then you must regenerate and deploy client-side certificates with the Digital Signature attribute set.
2. Update the server-side binaries.
3. Update the client-side binaries.

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.

1. If your current client-side identity certificates do not have the Digital Signature attribute set and the client connects directly to the MobiLink server, then you must regenerate and deploy client-side certificates with the Digital Signature attribute set.
2. Update the server-side binaries (remembering to include the new FIPS driver files) and deploy server identity certificates with AES-encrypted private keys.
3. Update the client-side binaries (remembering to include the new FIPS driver files) and deploy client identity certificates with AES-encrypted private keys.

Using FIPS and end-to-end encryption

1. Regenerate the primary key file referenced by the e2ee_private_key encryption option.
2. Shut down the MobiLink server.
3. Update the MobiLink server binaries, remembering to include the new required FIPS driver files.
4. Change the e2ee_private_key option to point to the new private key file (or replace the old file), updating the e2ee_private_key_password, if required.
5. Restart the MobiLink server.

Other

• The Windows 32-bit server will now load the dbfips DLL on startup if it is available. This is to ensure that the DLL loads in the correct place in memory, which is less likely to happen if we allocate the cache before loading it. This is not necessary on Linux or 64-bit Windows. If the DLL is not found, no error will be displayed until an attempt is made to actually use the FIPS library. There should be no behaviour changes associated with this, but you may notice that the FIPS DLL is loaded despite no attempt to use it.
• If you are running 32-bit software on a machine with 64-bit Windows installed, FIPS is no longer available. You must use 64-bit software on 64-bit Windows to use FIPS.