Known issues in OpenEdge 12.8.12

Summary
OpenEdge 12.8.12 ships with Apache HttpClient 5.6.1, which changes how TLS hostname verification is performed. This may affect applications connecting to HTTPS endpoints whose server certificates do not include a Subject Alternative Name (SAN) DNS entry matching the target hostname.
What Changed
Hostname verification now uses HostnameVerificationPolicy.BOTH. Under this policy, the hostname is verified twice:

1. By the JDK's JSSE engine during the TLS handshake, and
2. By HttpClient after the handshake completes.

In prior releases, HttpClient performed hostname verification only after the handshake (HostnameVerificationPolicy.CLIENT). The certificate must now satisfy both checks for the connection to succeed. 
As a result:

• The JDK's built-in endpoint identification algorithm governs the in-handshake check, following the rules defined in RFC 6125.
• When a server certificate presents a Subject Alternative Name (SAN) entry of type DNS name (DNSName), the Subject Common Name (CN) is no longer evaluated. If the target hostname does not match any of the certificate's SAN DNSName entries, the connection will be rejected with an SSLPeerUnverifiedException.
• This conforms to RFC 6125, under which a client must not fall back to CN matching when the certificate presents a DNS-ID (a SAN dNSName entry). 

This change affects environments where:*

• Server certificates rely solely on the Common Name (CN) field and do not include a SAN dNSName entry matching the connection hostname.

• Applications connect to endpoints whose certificates were previously accepted under the more lenient post-handshake verification, since verification is now additionally enforced by the JDK during the handshake.

Affected OpenEdge components:

• Java Open Client — connections to HTTPS-enabled PASOE endpoints.
• Components those consume Java Open Client, like ESBAdapter, may be impacted.

Recommended Action

Ensure that all target server certificates include SAN DNSName entries that match the hostname used in the connection URL. Certificates issued by public Certificate Authorities since approximately 2017 typically include proper SAN entries and require no changes.

A bug introduced in OpenEdge 12.3 caused ABL indeterminate arrays that are initialized with constant values to give an incorrect value for the EXTENT() function. This issue affected ABL programs that declare an indeterminate array variable using the EXTENT keyword without specifying a size and initialize it with a list of constant values (e.g., DEFINE VARIABLE myArr AS INTEGER EXTENT INITIAL [1, 2].), and this DEFINE comes after a statement that causes the execution of the EXTENT() function. In affected versions, the extent of such arrays was not correctly determined at compile time, resulting in incorrect runtime behavior.

This issue is resolved in 12.8.12 and 13.1. Recompilation is required for any ABL program that declares indeterminate arrays initialized with constant values. Programs that use determinate arrays (where the extent size is explicitly specified) do not require recompilation.

This fix introduces a minor r-code version change for ABL code that contains indeterminate LONGCHAR arrays where any element is initialized with the UNKNOWN value (?). R-code compiled with this fix cannot run on OpenEdge 13 releases earlier than 13.1, or on OpenEdge 12 releases earlier than 12.8.12.  

Starting in OpenEdge 12.8.12, $DLC/java/ext/slf4j-api-<version>.jar must be explicitly packaged alongside o4glrt.jar.

This release upgrades the bundled Apache Tomcat to version 10.1.56.

In this version, the HTTPS Connector attribute strictSni is enabled by default (true). When enabled, Tomcat enforces validation to ensure the TLS Server Name Indication (SNI) host matches the configured HTTP virtual host. Certain load balancer or proxy configurations may experience rejected HTTPS requests after upgrading.

To retain previous behavior, you may set strictSni="false" in the HTTPS Connector configuration. However, disabling this setting is not recommended, as the default configuration improves security.

In OpenEdge 12.8.11, 13.0, and later versions, users may see a Windows Defender exclusion prompt when launching Progress Developer Studio for OpenEdge (Developer Studio) on Windows systems with Windows Defender real-time protection enabled.

This prompt was introduced with the upgrade to Eclipse 4.34. Previously, no Windows Defender prompt appeared at startup. Now, users may see a prompt that allows them to choose one of the following options:

Exclude: Excludes the Developer Studio installation directory from Windows Defender scans to improve startup and build performance. However, this exclusion may increase security risk.

Continue scanning: Keeps Windows Defender scanning enabled and leaves the existing security configuration unchanged.

This behavior originates in the Eclipse platform and is not specific to Developer Studio. Users can review or remove an exclusion at any time from Windows Security > Virus & threat protection > Exclusions.

Reference: Eclipse Windows Defender documentation.