SSL im Play Framework verursacht 'Allgemeines SSLEngine-Probleme' (nginx)

Question

Ich habe eine Serverstruktur von 2 Servern: Einer ist der Hauptserver mit dem Inhalt und der andere ist ein Scala-Server mit Play, der das Benutzermanagement inklusive des sozialen Logins (fb, tw, g+) durchführt. Beide Server verwenden dasselbe Wildcard SSL-Zertifikat.

Ich habe kürzlich auf dem Hauptserver von Apache auf nginx umgestellt und aus irgendeinem Grund beschwert sich der Scala-Server über den SSL-Missmatch (was unter Apache noch nie ein Problem war).

Wenn ich versuche, mich anzumelden, erhalte ich den folgenden Fehler von Play:

[error] s.c.ProviderController - Benutzer konnte nicht angemeldet werden. Es wurde eine Ausnahme ausgelöst
java.net.ConnectException: Allgemeines SSLEngine-Problem zu https://www.example.com/login/corsValid
    at com.ning.http.client.providers.netty.NettyConnectListener.operationComplete(NettyConnectListener.java:103) ~[async-http-client.jar:na]
    at org.jboss.netty.channel.DefaultChannelFuture.notifyListener(DefaultChannelFuture.java:427) ~[netty.jar:na]
    at org.jboss.netty.channel.DefaultChannelFuture.notifyListeners(DefaultChannelFuture.java:413) ~[netty.jar:na]
    at org.jboss.netty.channel.DefaultChannelFuture.setFailure(DefaultChannelFuture.java:380) ~[netty.jar:na]
    at org.jboss.netty.handler.ssl.SslHandler.setHandshakeFailure(SslHandler.java:1417) ~[netty.jar:na]
    at org.jboss.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1293) ~[netty.jar:na]
Verursacht durch: javax.net.ssl.SSLHandshakeException: Allgemeines SSLEngine-Problem
    at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1290) ~[na:1.7.0_51]
    at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:513) ~[na:1.7.0_51]
    at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:793) ~[na:1.7.0_51]
    at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:761) ~[na:1.7.0_51]
    at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) ~[na:1.7.0_51]
    at org.jboss.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1225) ~[netty.jar:na]
Verursacht durch: javax.net.ssl.SSLHandshakeException: Allgemeines SSLEngine-Problem
    at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) ~[na:1.7.0_51]
    at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1694) ~[na:1.7.0_51]
    at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:278) ~[na:1.7.0_51]
    at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:270) ~[na:1.7.0_51]
    at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1341) ~[na:1.7.0_51]
    at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:153) ~[na:1.7.0_51]
Verursacht durch: sun.security.validator.ValidatorException: PKIX-Pfadkonstruktion fehlgeschlagen: sun.security.provider.certpath.SunCertPathBuilderException: Es konnte kein gültiger Zertifikatspfad zum angeforderten Ziel gefunden werden
    at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:385) ~[na:1.7.0_51]
    at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292) ~[na:1.7.0_51]
    at sun.security.validator.Validator.validate(Validator.java:260) ~[na:1.7.0_51]
    at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:326) ~[na:1.7.0_51]
    at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:283) ~[na:1.7.0_51]
    at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:138) ~[na:1.7.0_51]
Verursacht durch: sun.security.provider.certpath.SunCertPathBuilderException: Es konnte kein gültiger Zertifikatspfad zum angeforderten Ziel gefunden werden
    at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:196) ~[na:1.7.0_51]
    at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:268) ~[na:1.7.0_51]
    at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:380) ~[na:1.7.0_51]
    at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292) ~[na:1.7.0_51]
    at sun.security.validator.Validator.validate(Validator.java:260) ~[na:1.7.0_51]
    at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:326) ~[na:1.7.0_51]

Ich habe das Problem zurückverfolgt und herausgefunden, dass die application.conf korrekte Parameter für die verwendeten SSL-Zertifikate enthalten muss. Ich habe ein JKS- und P12-Zertifikat erstellt und in die Konfigurationsdatei aufgenommen, aber ich erhalte immer noch diesen Fehler. (Vielleicht falscher Pfad? Habe das auch versucht...)

ws.ssl {
  trustManager = {
    stores = [
      { path: "ssl.jks" }
    ]
  }
}

Wenn ich jedoch stattdessen ws.acceptAnyCertificate=true hinzufüge, funktioniert alles einwandfrei, aber das ist eindeutig eine Sicherheitslücke und nichts, was ich tun möchte.

Warum ist es so schwierig, ein SSL-Zertifikat in Play zu installieren?

Danke

Answer 1

Ich denke, Play ist hauptsächlich ein Anwendungs-Framework, kein Webserver.

Unsere Play-Apps kommunizieren immer ungesichert mit dem Nginx-Webserver (in der DMZ), die SSL/TLS-Kommunikation wird mit Nginx beendet. Mit diesem Design können Sie Lastverteilung vornehmen, wenn Ihre Play-App zustandslos ist.

Dann können Sie, wenn Sie möchten, alles in benutzerdefinierten HTTP-Headern von Nginx an den Backend weiterleiten (z. B. Client-Zertifizierung) zur Validierung.

proxy_set_header APP-Cert-Verified $ssl_client_verify;
proxy_set_header APP-Client-Cert $ssl_client_cert;
proxy_set_header APP-Client-Cert-DN $ssl_client_s_dn;

Sie können dies auch in der offiziellen Dokumentation finden: https://www.playframework.com/documentation/2.5.x/HTTPServer#Set-up-with-nginx.

Bonus: Wenn das Zertifikat abläuft, können Sie die Zertifikate in Nginx leichter ändern als Ihre Play-App neu zu starten.