ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Levas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMBARI-14778) Ambari Server CA should use sha265 as default message digest algorthm
Date Tue, 26 Jan 2016 01:01:49 GMT

    [ https://issues.apache.org/jira/browse/AMBARI-14778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15116424#comment-15116424
] 

Robert Levas commented on AMBARI-14778:
---------------------------------------

[~jimbobhickville],  I tested with Oracle Java 1.7 and 1.8 as well as OpenJDK 1.8.  It appears
that this algorithm is supported in the JVMs that Ambari supports.  As a fall back, we can
always edit the ca.config file and change the message digest algorithm as needed.

> Ambari Server CA should use sha265 as default message digest algorthm
> ---------------------------------------------------------------------
>
>                 Key: AMBARI-14778
>                 URL: https://issues.apache.org/jira/browse/AMBARI-14778
>             Project: Ambari
>          Issue Type: Bug
>          Components: ambari-server
>    Affects Versions: 2.1.1
>            Reporter: Robert Levas
>            Assignee: Robert Levas
>             Fix For: 2.2.2
>
>
> The Ambari Server (built-in) CA should use {{SHA265}} as default message digest algorithm
rather than the no longer trusted {{MD5}} and {{SHA1}} digest algorithms.
> To do this, change the following line (in both the unix and windows version of the file):
> {code:title=ambari-server/conf/unix/ca.config}
> default_md             = md5 
> {code}
> To
> {code:title=ambari-server/conf/unix/ca.config}
> default_md             = sha256
> {code}
> Note: This directly affects 2-way SSL between Ambari server and the agents due to security
constraints in newer JVMs, like 
> {noformat}
> openjdk version "1.8.0_71"
> OpenJDK Runtime Environment (build 1.8.0_71-b15)
> OpenJDK 64-Bit Server VM (build 25.71-b15, mixed mode)
> {noformat}
> The following error in the ambari-agent log may indicate that the agent's SSL certificate
is signed using MD5:
> {noformat:title=ambari-agent.log}
> ERROR 2016-01-22 17:01:56,982 Controller.py:186 - Unable to connect to: https://c6501.ambari.apache.org:8441/agent/v1/register/c6502.ambari.apache.org
> Traceback (most recent call last):
>   File "/usr/lib/python2.6/site-packages/ambari_agent/Controller.py", line 140, in registerWithServer
>     ret = self.sendRequest(self.registerUrl, data)
>   File "/usr/lib/python2.6/site-packages/ambari_agent/Controller.py", line 413, in sendRequest
>     raise IOError('Request to {0} failed due to {1}'.format(url, str(exception)))
> IOError: Request to https://c6501.ambari.apache.org:8441/agent/v1/register/c6502.ambari.apache.org
failed due to [Errno 8] _ssl.c:492: EOF occurred in violation of protocol
> ERROR 2016-01-22 17:01:56,982 Controller.py:187 - Error:Request to https://c6501.ambari.apache.org:8441/agent/v1/register/c6502.ambari.apache.org
failed due to [Errno 8] _ssl.c:492: EOF occurred in violation of protocol
> {noformat}
> The following error in the ambari-server log (when logging DEBUG messages) indicates
that the agent's SSL certificate is signed using MD5, which is not supported by the underling
JVM:
> {noformat:title=ambari-server.log}
> 22 Jan 2016 21:09:43,577 DEBUG [qtp-ambari-agent-50] HttpParser:1049 -
> javax.net.ssl.SSLHandshakeException: General SSLEngine problem
>         at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1431)
>         at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
>         at sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1214)
>         at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1186)
>         at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469)
>         at org.eclipse.jetty.io.nio.SslConnection.wrap(SslConnection.java:465)
>         at org.eclipse.jetty.io.nio.SslConnection.process(SslConnection.java:386)
>         at org.eclipse.jetty.io.nio.SslConnection.access$900(SslConnection.java:48)
>         at org.eclipse.jetty.io.nio.SslConnection$SslEndPoint.fill(SslConnection.java:715)
>         at org.eclipse.jetty.http.HttpParser.fill(HttpParser.java:1044)
>         at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:280)
>         at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>         at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
>         at org.eclipse.jetty.io.nio.SslConnection.handle(SslConnection.java:196)
>         at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
>         at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
>         at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>         at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>         at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
>         at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>         at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
>         at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:304)
>         at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
>         at sun.security.ssl.ServerHandshaker.clientCertificate(ServerHandshaker.java:1909)
>         at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:230)
>         at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
>         at sun.security.ssl.Handshaker$1.run(Handshaker.java:919)
>         at sun.security.ssl.Handshaker$1.run(Handshaker.java:916)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1369)
>         at org.eclipse.jetty.io.nio.SslConnection.process(SslConnection.java:375)
>         ... 12 more
> Caused by: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException:
Algorithm constraints check failed: MD5withRSA
>         at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:352)
>         at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:249)
>         at sun.security.validator.Validator.validate(Validator.java:260)
>         at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
>         at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:279)
>         at sun.security.ssl.X509TrustManagerImpl.checkClientTrusted(X509TrustManagerImpl.java:130)
>         at sun.security.ssl.ServerHandshaker.clientCertificate(ServerHandshaker.java:1896)
>         ... 19 more
> Caused by: java.security.cert.CertPathValidatorException: Algorithm constraints check
failed: MD5withRSA
>         at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:135)
>         at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:219)
>         at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:140)
>         at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:79)
>         at java.security.cert.CertPathValidator.validate(CertPathValidator.java:292)
>         at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:347)
>         ... 25 more
> {noformat}
> *Workaround*
> To work around this, the ambari-agent SSL certificates need to be regenerated using a
more secure digest algorithm, like {{SHA256}}.  To do this, first edit the Ambari server {{ca.config}}
file at {{/var/lib/ambari-server/keys/ca.config}} to change 
> {code}
> default_md             = md5 
> {code}
> to
> {code}
> default_md             = sha256 
> {code}
> The Ambari server does not need to be restarted.
> Then on each host of the cluster, remove the {{crt}} and {{key}} files from {{/var/lib/ambari-agent/keys/}}
and restart the agent. For example:
> {noformat}
> rm /var/lib/ambari-agent/keys/HOSTAME.*
> ambari-agent restart
> {noformat}
> _Replacing HOSTNAME with the name of the relevant host_



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message