To request that Virtalis Reach import a file, you specify the URL that its Translator Service will download the file from and, optionally, the URL that its Job API will notify on completion of the translation. A request to an HTTPS URL that is secured with an untrusted certificate, for example for an internal service in an organisation or for testing purposes, will fail. This document explains how to enable certificates to be trusted by Virtalis Reach by adding them to the secrets of the Translator Service and the Job API.
Certificates can be loaded in the secrets of the Translator Service and the Job API to specify they should be accepted as trusted. Each certificate will be logged at start-up as it’s loaded by the Translator Service and, if there are any errors loading them or requesting any resources, that will also be logged appropriately. After the certificates have been loaded, those certificates will be trusted and external requests to servers using those certificates will succeed.
Please note: You may need to configure this for both the Translator Service and the Job API, since there are two places where external HTTP requests are made: the translator service can download data from the specified URL, and the Job API can optionally call to an external URL when a submitted job is complete.
Secrets for further information if you are not familiar with this feature of Kubernetes.
How to Use Self-signed Certificates in the Platform
Adding a certificate assumes that you already have an HTTPS server set up with a self-signed certificate. Certificates in PEM format are supported, for example:
Once you have your certificate in this format, save it, for example as “example.crt”, and add it to the Translator Service as a secret. Then update the main TranslatorServiceSecrets to include the secret name in the “Certificates” field. For example:
You may need to do this to both the Translator Service secrets and the Job API secrets, as noted above.
Then, when importing an asset, use your HTTPS server's URL in the translation message to download the file and then optionally use JobCallbackUrl to call the external service to report that the job has completed successfully.
If this exception message occurs, check the certificate file specified, as it may have been formatted incorrectly.
If this exception message occurs, check the certificate expiration date, as it is most likely expired. The default expiration date is one year for a certificate that is issued by a Stand-alone Certificate Authority CA.
Under this error message it should list the chain errors and the reason behind them that have occurred. If an UntrustedRoot error is listed as the only error, then the problem is that the certificate used by the server is not configured as a trusted certificate.
If this error message occurs, the policy error will be either “RemoteCertificateNotAvailable” or “RemoteCertificateNameMismatch”, which indicates that there’s some configuration issue with the remote server’s certificate beyond its trusted status.