Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

Unable to access repo.adobe.com via maven

Avatar

Level 3

Hi,

I get the following error when I do a build using maven. This stared a few days back.

Failed to read artifact descriptor for com.adobe.aem:aem-api:jar:6.0.0.1: Could not transfer artifact com.adobe.aem:aem-api:pom:6.0.0.1 from/to adobe (http://repo.adobe.com/nexus/content/groups/public/): Received fatal alert: handshake_failure 

Tried the below to solve the issue but no success

  1. Imported the certificate a trusted
  2. Forced Maven to ignore SSL issues

Is anybody else facing the same issue?

Thank you.

Cheers,

VIren.

1 Accepted Solution

Avatar

Correct answer by
Level 2

We ran into some problems recently, I think they may be switching the repo to SSL, and not everything is redirecting correctly.  I changed the repository settings references to https://repo.adobe and that seemed to resolve our problems.

View solution in original post

0 Replies

Avatar

Correct answer by
Level 2

We ran into some problems recently, I think they may be switching the repo to SSL, and not everything is redirecting correctly.  I changed the repository settings references to https://repo.adobe and that seemed to resolve our problems.

Avatar

Level 9

There could be couple of reasons for  handshake failure:

  • Unsupported or Incompatible cipher suites in use by the client and the server.
  • Incompatible versions of SSL in use (the server might accept only TLS v1, while the client is capable of only using SSL v3). Again, the client might have to ensure that it uses a compatible version of the SSL/TLS protocol.
  • Incomplete trust path for the server certificate; the server's certificate is probably not trusted by the client. This would usually result in a more verbose error, but it is quite possible. Usually the fix is to import the server's CA certificate into the client's trust store.
  • The cerificate is issued for a different domain. Again, this would have resulted in a more verbose message,but I'll state the fix here in case this is the cause. The resolution in this case would be get the server (it does not appear to be yours) to use the correct certificate.

Since, the underlying failure cannot be pinpointed, it is better to switch on the -Djavax.net.debug=all flag to enable debugging of the SSL connection established. With the debug switched on, you can pinpoint what activity in the handshake has failed.