Good question!

You can "trust" the certificate, click on the red bar "details"



Then "modify trust" and Trust the certificate



Follow the steps and install the certificate, when done the next time you open the mail the red warning will not show anymore

My certificate lead to a trusted Certificate Authority!

So the trusted status should be matched automatically.

what shows in the details for reason, you see 2 reasons for my certificate and one is the non trusted CA

The reason shows passed....

Can you open a case and provide the mail as EML file for testing ?

Good evening Martin. I am now writing from the green table because I am missing a lot of background information. I know the error you describe from the field. Incidentally, the issue is independent of the mail client. I assume that you can handle openssl very well, which you will need later for analysis. From my support calls, I often see that the chain for a certificate is incomplete or that the intermediate certificate is not considered valid because the certificate source cannot be reloaded or the issuer of the certificate is not available in the client's local trust store. Verification or reloading can sometimes also fail if the client had problems with Winsock due to a virus scanner or after a malware infection.

As a first step, it is therefore important to approach the certificate marked as faulty with OpenSSL and analyze it. If openssl does not show a chain error, which seems to be the case here, you must then check the client side and the GroupWise client. If it turns out that the mail is considered valid after the second load, it must be further checked why the intermediate certificate is considered questionable the first time. The issue may also lie on the source side. In larger institutions, I recommend considering setting up a PKI infrastructure. The reasons for this are not discussed here, but the issue is to create a secure platform, especially as far as certificates are

Please follow Rob's advice to open a call.

George

Case has been opened. Rob reported a defect ...

Thanks for the info, so far I could see that the winproxy from MS often blocked requests for the root CA.

It seems a client issue, when i got the EML I simply did this :

- Drag EML in client

- Open email

- I see the error/red bar

- Close the email without doing anything

- Open email again

- No error/red bar anymore

So this brings it back to the basics, only on first opening the error shows while the info in the certificate is correct and the are no "fails" reported so the defect i opened is to skip the first error as when the client can open it the second time without me doing anything it also should be able to do this the first time.