2

When attempting a file upload to an Alfresco Server using ssl the server logs show no errors. The below error can be pulled from the clients logs.

javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated

Certificates have been checked, and are valid. From this error is it possible to tell if the error is occuring on the server or client side of the ssl handshake?

I would assume that it is client side since the server shows no log entries but am not confident in my answer. Could it be that the client has an invalid certificate for the server, and it needs to be reimported as a trusted source?

New information:

The javadoc for SSLPeerUnVerifedException mentions that "the peer was not able to identify itself.". So I am led to believe that my guess stands that something needs to be addressed on the client machine?

I am unsure if this kind of question belongs here or on Serverfault, but feel free to vote to move.

I have also floated the question over on ServerFault in a different fashion.

Community
  • 1
  • 1
sealz
  • 5,348
  • 5
  • 40
  • 70
  • Which application server are you running Alfresco in? Is there any frontend, e.g. Apache httpd or NginX? – skuro Feb 08 '12 at 15:27
  • I am very new to alfresco and the works so I am learning by fire here. It uses tomcat. – sealz Feb 08 '12 at 15:30

1 Answers1

2

Alfresco does not ship a trusted (!=valid) certificate and the only SSL based communication used out of the box is between the repository and solr (since alfresco 4.0).

Nevertheless, the symptoms pretty much look like the client does not accept an untrusted certificate presented by the server. Validity (as in expiration date) is a different story.

Anyways, the fairly commonly used apache httpclient has to be "prepared" to accept and work with untrusted certificates. You should definitely check http://javaskeleton.blogspot.com/2010/07/avoiding-peer-not-authenticated-with.html if you are using it. Usually, you only import untrusted certificates. I don't know any reason to import trusted ones.

Andreas Steffan
  • 6,039
  • 2
  • 23
  • 25
  • Thanks this is what I was leaning toward. The cert has been prepared. Some more research says that If something serverside was failing there would be a handshake exception in the server logs. – sealz Feb 08 '12 at 17:16
  • @Andres Steffan Certs have been sent to the client to validate/import but the same error is still present. Any possibility that its a server settings that is misconfigured? Would a tomcat restart be required? – sealz Feb 09 '12 at 13:02
  • 2
    I'm fairly sure the cause is an untrusted cert sent by the server. Try the code from the blogpost using dev=true/false against our server. If it fails with dev=true and works with dev=true you can be certain the server is presenting you an untrusted cert. Then fix the cert on the server or use a client accepting an untrusted cert. – Andreas Steffan Feb 09 '12 at 17:23
  • Thanks again, the problem ended up being a certificate not being trusted ont eh client machine. – sealz Feb 09 '12 at 17:59