xcp wait for email on gmail working for anyone?

Hi all,

I have tried to setup a "Wait for email" activity to be able to monitor a gmail account (end point), but no matter what I try, I get this error:

2014-08-06T15:40:21.912-0400 ERROR [TThread-30] [] [com.documentum.bps.email.inbound.runtime.EmailPoller:91] Could not retrieve messages from mail server: imap.gmail.com

javax.mail.MessagingException: Certificate not verified.;

nested exception is:

javax.net.ssl.SSLException: Certificate not verified.

at com.sun.mail.imap.IMAPStore.protocolConnect(IMAPStore.java:618)

at javax.mail.Service.connect(Service.java:291)

at com.documentum.bps.email.EmailUtils.createEmailStore(EmailUtils.java:148)

at com.documentum.bps.email.inbound.runtime.EmailStorePool.createEmailStore(EmailStorePool.java:134)

at com.documentum.bps.email.inbound.runtime.EmailStorePool.getEmailStoreFromPool(EmailStorePool.java:123)

at com.documentum.bps.email.inbound.runtime.EmailStorePool.getEmailStore(EmailStorePool.java:71)

at com.documentum.bps.email.inbound.runtime.EmailPoller.run(EmailPoller.java:65)

at java.lang.Thread.run(Thread.java:722)

Caused by: javax.net.ssl.SSLException: Certificate not verified.

at com.rsa.sslj.x.aE.b(Unknown Source)

at com.rsa.sslj.x.aE.a(Unknown Source)

at com.rsa.sslj.x.aP.c(Unknown Source)

at com.rsa.sslj.x.aP.a(Unknown Source)

at com.rsa.sslj.x.aP.h(Unknown Source)

at com.rsa.sslj.x.cy.startHandshake(Unknown Source)

at com.sun.mail.util.SocketFetcher.configureSSLSocket(SocketFetcher.java:503)

at com.sun.mail.util.SocketFetcher.getSocket(SocketFetcher.java:234)

at com.sun.mail.iap.Protocol.<init>(Protocol.java:109)

at com.sun.mail.imap.protocol.IMAPProtocol.<init>(IMAPProtocol.java:104)

at com.sun.mail.imap.IMAPStore.protocolConnect(IMAPStore.java:585)

... 7 more

Caused by: com.rsa.sslj.x.g: Certificate not verified.

at com.rsa.sslj.x.cE.a(Unknown Source)

at com.rsa.sslj.x.cE.b(Unknown Source)

at com.rsa.sslj.x.cE.a(Unknown Source)

... 18 more

Caused by: java.security.cert.CertificateException: the certificate chain is not trusted, Parameters must be PKIXParameters or be CertPathWithOCSPParameters containing PKIXParameters

at com.rsa.sslj.x.ad.a(Unknown Source)

at com.rsa.sslj.x.ad.checkServerTrusted(Unknown Source)

at com.documentum.bps.email.ssl.BPSEmailX509TrustManager.checkServerTrusted(BPSEmailX509TrustManager.java:48)

at com.rsa.sslj.x.bv.a(Unknown Source)

... 21 more

I have load the gmail certificate in the JVM truststore, but I keep getting the same message. I have explicitly told the JVM which truststore to use but still getting the error. I'm getting the same error on hotmail too. So I was wondering if anyone manage to get this to work.

I was also wondering if there is a config element in BPS that we could instruct it not to validate the Certificats (just of testing purposes oviously!)

Cheers

Alain

Find more posts tagged with

Comments

Abdoulaye

Did you find any resolution for this issue ? having the same error with the Send Mail Activity.

Thank you

eha

We're facing a similar problem with a custom Method (dm_method) which runs in a Job (dm_job) on the Java Method Server (JMS). The problem exists on both D6.7 SP1 (JBoss 5.1.0) and D7.1 (JBoss 7.1.1).

We are trying to connect to an Exchange Web Service (EWS) using EWS Java API over https. It worked flawlessly up until the EWS got issued new certificates. The certificates are perfectly fine, however our code complains about the certificate chain not being trusted, just as above.

There is a workaround for this, at least in Documentum 7.1, but we don't know yet whether it is a recommended approach:

Note that the stacktrace above involves com.rsa.sslj.*. When comparing the JRE bundled with Documentum (and that the JMS uses) we see that java.security has been modified to include two extra security providers:

com.rsa.jsse.JsseProvider
com.rsa.jsafe.provider.JsafeJCE

There's also a number of JAR files included that correspond to these providers. The java.security file lists providers in order of preference, so the workaround is to alter this order so that the default Java providers are used instead. Be sure to update the numbers, too. If the certificate you're validating is signed by a trusted CA, you should be OK. If you're using self-signed certificates, be sure to add your Root CA to the Java Trust Store.

To add Root CA to Java Trust Store, use keytool.exe provided by Oracle to modify cacerts which is the default Java Trust Store (also for the JRE that is bundled with Documentum). The default password for cacerts is changeit.

As for why the RSA security providers won't work with certain certificates, we don't know. But we suspect it might be connected to a bug in the RSA Java code. We got the problem with a new certificate which was 2-tier (having an Intermediate CA), whereas the old one that worked was a 1-tier certificate - but it might be other properties of the certificate which causes it to be invalid for Java RSA.

We are surely going to be in touch with EMC regarding this, as the workaround does change the default behaviour of Documentum and should be used with caution. Furthermore we haven't found any workaround for older Documentum versions yet, as these do not come with modified java.security files. But I hope this post kicks you in the right direction and that you might find a workaround that works for you.