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

Julia Kinga Marton edited comment on OOZIE-3157 at 1/23/18 3:40 PM:
--------------------------------------------------------------------

Thank you [~gezapeti] for the comments. Here you can find my answers:
 # I tested it in the following way: I set up Oozie locally (without HTTPS) and 
in the code I added a GET request to a HTTPS address and verified if I will get 
the exception mentioned in this issue or not.
 #  you are right. I will clean the system parameter values in the TearDown() 
part.


was (Author: kmarton):
Thank you [~gezapeti] for the comments. Here you can find my answers:
 # I tested it in the following way: I set up Oozie locally (without HTTPS) and 
in the code I added a GET request to our nightly server 
("[https://nightly6x-1.gce.cloudera.com:16000/kms/v1/|https://www.google.com/url?q=https://nightly6x-1.gce.cloudera.com:16000/kms/v1/&sa=D&ust=1516785809193000&usg=AFQjCNF8S1r2UeIeJkQkVsjHWjyRMFrbGw]";)
 and verified if I get HTTP ERROR 401 (Unauthorized access) instead of getting 
the exception mentioned in this issue.
 #  you are right. I will clean the system parameter values in the TearDown() 
part.

> Setup truststore so that it also works in HTTP only mode
> --------------------------------------------------------
>
>                 Key: OOZIE-3157
>                 URL: https://issues.apache.org/jira/browse/OOZIE-3157
>             Project: Oozie
>          Issue Type: Bug
>    Affects Versions: trunk, 5.0.0b1
>            Reporter: Attila Sasvari
>            Assignee: Julia Kinga Marton
>            Priority: Blocker
>             Fix For: 5.0.0
>
>         Attachments: OOZIE-3157-001.patch
>
>
> {{oozie.https.truststore.file}} is not read and used when 
> {{oozie.https.enabled}} is false in {{oozie-site xml}}. As a result, the 
> Oozie server will be unable to communicate with servers with unsigned 
> certificate. It is a critical problem as authentication may involve external 
> servers (for example KMS with self-signed certificate). Submitting a workflow 
> in such an environment can result in an exception like:
> {code}
> 2018-01-08 10:13:51,471 WARN 
> org.apache.hadoop.crypto.key.kms.LoadBalancingKMSClientProvider: 
> SERVER[myserver] KMS provider at [https://myserver:16000/kms/v1/] threw an 
> IOException: 
> javax.net.ssl.SSLHandshakeException: 
> sun.security.validator.ValidatorException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to
>  find valid certification path to requested target
>         at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>         at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1959)
>         at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
>         at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
>         at 
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1514)
>         at 
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
>         at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1026)
>         at sun.security.ssl.Handshaker.process_record(Handshaker.java:961)
>         at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072)
>         at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
>         at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
>         at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
>         at 
> sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
>         at 
> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
>         at 
> sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153)
>         at 
> org.apache.hadoop.security.authentication.client.KerberosAuthenticator.authenticate(KerberosAuthenticator.java:186)
>         at 
> org.apache.hadoop.security.token.delegation.web.DelegationTokenAuthenticator.authenticate(DelegationTokenAuthenticator.java:144)
>         at 
> org.apache.hadoop.security.authentication.client.AuthenticatedURL.openConnection(AuthenticatedURL.java:348)
>         at 
> org.apache.hadoop.security.token.delegation.web.DelegationTokenAuthenticatedURL.openConnection(DelegationTokenAuthenticatedURL.java:333)
>         at 
> org.apache.hadoop.crypto.key.kms.KMSClientProvider$1.run(KMSClientProvider.java:477)
>         at 
> org.apache.hadoop.crypto.key.kms.KMSClientProvider$1.run(KMSClientProvider.java:472)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at javax.security.auth.Subject.doAs(Subject.java:422)
>         at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1962)
>         at 
> org.apache.hadoop.crypto.key.kms.KMSClientProvider.createConnection(KMSClientProvider.java:471)
>         at 
> org.apache.hadoop.crypto.key.kms.KMSClientProvider.decryptEncryptedKey(KMSClientProvider.java:776)
>         at 
> org.apache.hadoop.crypto.key.kms.LoadBalancingKMSClientProvider$5.call(LoadBalancingKMSClientProvider.java:287)
>         at 
> org.apache.hadoop.crypto.key.kms.LoadBalancingKMSClientProvider$5.call(LoadBalancingKMSClientProvider.java:283)
>         at 
> org.apache.hadoop.crypto.key.kms.LoadBalancingKMSClientProvider.doOp(LoadBalancingKMSClientProvider.java:123)
>         at 
> org.apache.hadoop.crypto.key.kms.LoadBalancingKMSClientProvider.decryptEncryptedKey(LoadBalancingKMSClientProvider.java:283)
>         at 
> org.apache.hadoop.crypto.key.KeyProviderCryptoExtension.decryptEncryptedKey(KeyProviderCryptoExtension.java:532)
>         at 
> org.apache.hadoop.hdfs.DFSClient.decryptEncryptedDataEncryptionKey(DFSClient.java:926)
>         at 
> org.apache.hadoop.hdfs.DFSClient.createWrappedInputStream(DFSClient.java:945)
>         at 
> org.apache.hadoop.hdfs.DistributedFileSystem$4.doCall(DistributedFileSystem.java:315)
>         at 
> org.apache.hadoop.hdfs.DistributedFileSystem$4.doCall(DistributedFileSystem.java:310)
>         at 
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
>         at 
> org.apache.hadoop.hdfs.DistributedFileSystem.open(DistributedFileSystem.java:322)
>         at org.apache.hadoop.fs.FileSystem.open(FileSystem.java:949)
>         at 
> org.apache.oozie.service.AuthorizationService.authorizeForApp(AuthorizationService.java:392)
>         at 
> org.apache.oozie.servlet.BaseJobServlet.checkAuthorizationForApp(BaseJobServlet.java:263)
>         at 
> org.apache.oozie.servlet.BaseJobsServlet.doPost(BaseJobsServlet.java:99)
> {code}
> h4. Background
> - When 
> [EmbeddedOozieServer|https://github.com/apache/oozie/blob/e68f723a320f48a52f3266cce5c037916ebff3e0/server/src/main/java/org/apache/oozie/server/EmbeddedOozieServer.java#L124]
>  is created it checks if it is configured with HTTPS. If so it creates an 
> sslConnector that sets up keystore and truststore via 
> [SSLServerConnectorFactory 
> |https://github.com/apache/oozie/blob/e68f723a320f48a52f3266cce5c037916ebff3e0/server/src/main/java/org/apache/oozie/server/SSLServerConnectorFactory.java#L82]
>  using Jetty's SslContextFactory.
> - If we are not using HTTPS, truststore specified in Oozie configuration is 
> ignored. As a workaround we can pass {{javax.net.ssl.trustStore}} and 
> {{javax.net.ssl.trustStorePassword}} via system properties upon JVM startup 
> via the JETTY_OPTS environment variable.
> h4. A possible solution 
> - Set system property {{javax.net.ssl.trustStore}} and 
> {{javax.net.ssl.trustStorePassword}} with {{System.setProperty()}} using 
> Oozie configuration properties if they are not set by a user.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to