After upgrading DLP and OCR from 15.8 to 16.x or 25.1, the OCR server stops receiving images for text extraction. There are alerts 4807 "The client and/or OCR server are not authorized with each other" are produced on Enforce.
In the detection server logs (FileReader logs for 16.0.x builds, SymantecDLPDetectorX logs for 16.1 and 25.1), the following exception is logged:
com.vontu.messaging.chain.ocr.OcrExecutionTask call
WARNING: Failed to perform OCR for item 'TEST.JPG'
com.symantec.dlp.ocr.client.exception.OcrUnauthorizedException: OcrRequestId: [bc04b115-1a3f-41d0-93cb-635b5d348362] Unable to verify client and server with each other as authorized endpoints. Please verify that the client and server keystores are configured correctly. gRPC StatusRuntimeException: UNAVAILABLE - io exception
Channel Pipeline: [SslHandler#0, ProtocolNegotiators$ClientTlsHandler#0, WriteBufferingAndExceptionHandler#0, DefaultChannelPipeline$TailContext#0]
at com.symantec.dlp.ocr.client.grpc.OcrGrpcClient.lambda$runRequest$0(OcrGrpcClient.java:147)
at com.symantec.dlp.ocr.client.grpc.OcrGrpcClient$OcrRequestRetrier.run(OcrGrpcClient.java:279)
at com.symantec.dlp.ocr.client.grpc.OcrGrpcClient.runRequest(OcrGrpcClient.java:67)
at com.symantec.dlp.ocr.client.grpc.OcrClientOnPremGrpcType.submitRequest(OcrClientOnPremGrpcType.java:226)
at com.symantec.dlp.ocr.client.OcrClientOnPremBackCompatibleType$OcrClientChooser.submitRequest(OcrClientOnPremBackCompatibleType.java:291)
at com.symantec.dlp.ocr.client.OcrClientOnPremBackCompatibleType.submitRequest(OcrClientOnPremBackCompatibleType.java:118)
at com.vontu.messaging.chain.ocr.OcrExecutionTask.call(OcrExecutionTask.java:131)
at com.vontu.messaging.chain.ocr.OcrExecutionTask.call(OcrExecutionTask.java:62)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: io.grpc.StatusRuntimeException: UNAVAILABLE: io exception
Channel Pipeline: [SslHandler#0, ProtocolNegotiators$ClientTlsHandler#0, WriteBufferingAndExceptionHandler#0, DefaultChannelPipeline$TailContext#0]
at io.grpc.Status.asRuntimeException(Status.java:537)
at io.grpc.stub.ClientCalls$UnaryStreamToFuture.onClose(ClientCalls.java:548)
at io.grpc.internal.ClientCallImpl.closeObserver(ClientCallImpl.java:567)
at io.grpc.internal.ClientCallImpl.access$300(ClientCallImpl.java:71)
at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInternal(ClientCallImpl.java:735)
at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInContext(ClientCallImpl.java:716)
at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:133)
... 3 more
Caused by: io.grpc.netty.shaded.io.netty.handler.ssl.ReferenceCountedOpenSslEngine$OpenSslHandshakeException: error:1000042e:SSL routines:OPENSSL_internal:TLSV1_ALERT_PROTOCOL_VERSION
DLP and OCR upgraded from 15.8 to a newer version
The error is caused by a mismatch of TLS version used by the OCR server and by the DLP detection server. Newer versions of the OCR server will always attempt to use TLS 1.2 or 1.3 for the TLS handshakes with the detector. There was also a change in the certificate management and usage in OCR servers in versions 16.0 and newer, where instead of JKS keystores, the newer OCR now uses PEM files to store the certificates used for handshakes. Details of the new architecture can be found in the OCR documentation:
The TLS protocol mismatch can be caused if the DLP detection servers were upgraded to a newer DLP build without upgrading the JRE. On the detectors, all network communication is handled by JRE, which includes selection of TLS version for the handshakes. As a result, the DLP detectors continue to use the older JRE version that was used by the 15.8 pre-upgrade build. The older JRE will by default use an older TLS version for the handshakes, resulting in TLS version mismatch where OCR tries to handshake using TLS 1.2/1.3, and the detector responds with an older TLS version. This causes the TLSV1_ALERT_PROTOCOL_VERSION handshake failures.
Each DLP installation package downloaded from Broadcom Downloads includes a JRE version suitable for use with the specific DLP build. Each DLP version also supports different versions of the JRE. Below are the details of JRE supportability for different DLP versions:
DLP 15.8: 1.8.0_262 - 1.8.0_372
Symantec Data Loss Prevention System Requirements and Compatibility Guide, Version 15.8
DLP 16.0: 1.8.0_322 - 1.8.0_472
DLP 16.0 Required third-party software
DLP 16.0.1: 1.8.0_322 - 1.8.0_432
DLP 16.0.1 Required third-party software
DLP 16.0.2: 1.8.0_322 - 1.8.0_472
DLP 16.0.2 Required Third-party Software
DLP 16.1: 1.8.0_322 - 1.8.0_472
DLP 16.1 Required Third-party Software
DLP 25.1: 21.0.4 - 21.0.9
DLP 25.1 Third-party Software Requirements and Recommendations
The DLP upgrade process includes a step to deploy a newer JRE version which comes prepackaged with the DLP installation package for a given build, for example for DLP upgrades to 16.1, this step is documented here:
Install the Java Runtime Environment on the Enforce Server on Windows
This step should not be skipped when upgrading DLP to a newer version.
After upgrading JRE to a build provided with the specific already upgraded DLP version, the TLS handshakes between OCR and DLP detection servers is confirmed to work.