SSL Frequently Asked Questions (FAQ) and Return Codes for the IBM i (iSeries, System i, AS/400)
Because a lot of our software uses Secure Sockets Layer (SSL/TLS) we run into many errors returned by the APIs used.
In this article we are going to point you to our SSL FAQ page as well as list some of the most common SSL return codes, their meanings and the circumstances in which we find they occur.
The SSL Documentation can be found here.
Please see this article on how to set your system's SSL or TLS version on your IBM i.
The following is a list of command SSL error codes and our descriptions:
- -1 - SSL_ERROR_NO_CIPHERS - This error shouldn't happen often, but if it does it most likely is because you are on an older version of the OS and new ciphers used by the SSL certificate on the server you are connecting to are not installed on your system. If you are on an unsupported OS version there really is nothing you can do. If you are on a supported OS, find out which cipher is being used and check your SSL cipher list by displaying the system value (DSPSYSVAL) for QSSLCSL. Then contact SSL support to see if a PTF is available to update the cipher list on your machine.
- -2 - SSL_ERROR_NO_CERTIFICATE - This error normally occurs when you are communicating with a server that requires that you use a client side certificate and one has not been provided. This is normally done by creating an application ID in Digital Certificate Manager (DCM) and assigning the client side certificate you were supplied to this application ID. You then specify the application ID on the client (such as GETURI) that you are using.
- -10 - SSL_ERROR_IO - Depending on the Error Number (errno) returned, this could mean one of many things. If it's a permission error (3401), see the SSL FAQ section about which folders need permissions to fix this error. If the error number is 3426 this normally means that you don't have your system set up to use TLS v1.2 ciphers.
- -11 or -16 - SSL_ERROR_BAD_MESSAGE or SSL_ERROR_BAD_PEER - This normally occurs when you don't specify the proper port when communicating via SSL. For example, with GETURI the default port is 80, even if you specify SSL(*YES). So, we often see this return code when the port is not changed to 443 for SSL communications.
- -13 - SSL_ERROR_NOT_SUPPORTED - This normally means that the SSL Certificate used by the server is not compatible with the available cipher suites set up on your system. This is rare unless you're on an old or unsupported OS version (maybe even V7R1). See this article for a possible workaround.
- -23 - SSL_ERROR_NOT_TRUSTED_ROOT - See the above note about this error.
- -24 - SSL_ERROR_CERT_EXPIRED - This normally means that you have a Certificate Authority (CA) or a certificate (self-signed or signed by a trusted authority) that has expired. On V6R1 and up in Digital Certificate Manager (DCM) when viewing CAs or certificates there is a "Check Expiration" button you can click to view expired CAs and/or Certificates. Even if this CA or Certificate(s) that is expired has nothing to do with your application, it can cause issues. (Don't ask me why). Delete the expired CA(s) and/or certificates(s) and you should be back in action.
- -93 - SSL_ERROR_NOT_AVAILABLE - This error usually occurs when you have not yet set up your *SYSTEM certificate Store. Click Here for more information on performing this function.
- -95 - SSL_ERROR_NO_KEYRING - This error is similar to -93. Make sure that you have created your *SYSTEM store and the default CAs were installed.
As we encounter more errors we will update this list. As always, do feel free to contact us with any questions.
Last edited 04/26/2018 at 07:44:12