Catch TLS errors
- Last Updated: March 4, 2026
- 7 minute read
- OpenEdge
- Version 12.8
- Documentation
error #9318, which is an internal error caused by a
failure at the TLS layer (SSL). You can use the following pattern to recognize this
error message:
|
As part of the Client Authentication introduced in OpenEdge 12.4, a new error class is
introduced to isolate and translate common internal errors thrown by this TLS layer
(SSL) failure. For example, in case of error# 9318 the HTTP Client
throws a Progress.Lang.Error object of type
OpenEdge.Net.ServerConnection.TlsClientAuthenticationError, which is
handled by either checking the TypeName of the class of the object or
by explicitly catching the error by type.
HTTPS request. These messages are always
presented in the following order:- The inner error number extracted from the SSL failure (
9318) error. - The hostname of the destination URI.
- The port number of the destination URI.
- The original SSL failure (
9318) message with the full inner error number or message.
TLS v1.3 the default for HTTPS which results in
several new error messages that the end-user may see more regularly. These error
messages must be mapped to generic messages for security reasons. The exact reason and
error numbers used for mapping these error messages to generic messages are subject to
change though there are some categories which are trapped and returned in a generic
manner. For example:- Group Authorization Failed—Returned when TLS Supported Groups are utilized but are not supported by the remote server.
- User Authentication Failed—Returned when TLS Client Authentication is utilized but a client certificate is not found, or the passkey is incorrect.
For all other situations, you must use the inner error number and optionally the destination host or port to determine the best message and verbosity required to assist end-users.
InnerError property of the
object instance to access the original SysError object thrown from
the #9318 SSL failure.TlsClientAuthenticationError object:- The format of the fourth error message is now always a translated condition
related to the inner error number from the SSL failure. In case the inner error
cannot be mapped to a safe and known message, the generic
Unknown TLS Erroris supplied as the message. - New instance properties are added to the object class to provide direct access
to the internal values parsed and normally returned using the following message
statements:
Host—The hostname of the destination URI.Port—The port number of the destination URI.TlsErrorNum—The inner error number extracted from the SSL failure (9318) error.TlsError—The original SSL failure (9318) message with the full inner error number or message.
- A static property
ReturnOriginalMessagesis added, which forces theTlsClientAuthenticationErrorclass to always return the originalSysErrormessages, in order and exactly as formatted from the original error object.- To enable this behavior, set the
TlsClientAuthenticationError:ReturnOriginalMessagesstatic property totrue. - To return to the new message statement behavior, return the property to
its default of
false. - You can change the property before and then after
HttpClientrequest to force specific behavior for only that request, or set totrueonce at the start of an AVM session, such as by use of asessionStartupProcin PAS for OpenEdge, to globally enforce the behavior for an application.
- To enable this behavior, set the
Example
In this example, making a request to an unknown host will result in error
#9318 that is returned with an inner TLS error of
11001, which indicates the request was unable to find the
destination host.
As a developer, you can trap this error number for further translation and either return it to the end-user or send the details to a log file. This allows the developer to decide when and which messages to return to an end-user as some of the information can be considered useful by a potential attacker. In such situations, it is always good to provide the least amount of information in the error messages.
TlsClientAuthenticationError which inherits
OpenEdge.Core.System.ApplicationError and thus makes the
InnerError property available. This InnerError
property contains the original Progress.Lang.SysError object. The
following ABL code would be most useful when the application code must support
multiple OpenEdge releases such as those prior to OpenEdge 12.4, when this error
object was introduced, to those releases available after the introduction of the
error object.
|
OpenEdge.Net.ServerConnection.TlsClientAuthenticationError
followed by a more general catch block for all other error
types.
|