configure DDF to use externally generated certificates

50 views
Skip to first unread message

dmc...@gmail.com

unread,
Aug 23, 2018, 4:11:01 AM8/23/18
to ddf-users
Hi,

I'm trying to configure DDF 2.11.6  to use externally generated certificates.  Starting with a working DDF instance (where i've ran the certnew script) I'm 

  • creating a new keystore file - /etc/keystores/serverKeystore2.jks  with the externally generated key, certificate and root certificate. The alias for the certificate is the <fqdn> for the server. The alias for the ca is the <fqdn> for the ca server
  • adding in the root certificate to /etc/keystores/serverTruststore.jks, again the alias is the <fqdn> for the ca server.
  • updating system.properties to point at the new keystore file.
The externally generated certificate has CN= <fqdn> for the server, and alternate name = DNS= <fqdn>.  It also has the same bit size (if that matters)
The entries in the user attributes, user properties, system properties  all match the fqdn and hence the certificate

When i start the system i'm getting errors like this:

2018-08-23T07:41:07,797 | WARN  | igParserThread 0 | HttpTransport                    | ogle.api.client.http.HttpRequest 1002 | 215 - security-core-api - 2.11.6 | exception thrown while
 executing request
java.net.SocketException: Broken pipe (Write failed)
        at java.net.SocketOutputStream.socketWrite0(Native Method) ~[?:?]
        at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111) ~[?:?]
        at java.net.SocketOutputStream.write(SocketOutputStream.java:155) ~[?:?]
        at sun.security.ssl.OutputRecord.writeBuffer(OutputRecord.java:431) ~[?:?]
        at sun.security.ssl.OutputRecord.write(OutputRecord.java:417) ~[?:?]
        at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:886) ~[?:?]
        at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:857) ~[?:?]
        at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:727) ~[?:?]
        at sun.security.ssl.Handshaker.sendChangeCipherSpec(Handshaker.java:1150) ~[?:?]
        at sun.security.ssl.ClientHandshaker.sendChangeCipherAndFinish(ClientHandshaker.java:1266) ~[?:?]
        at sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:1178) ~[?:?]
        at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:348) ~[?:?]
        at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052) ~[?:?]
        at sun.security.ssl.Handshaker.process_record(Handshaker.java:987) ~[?:?]
        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:162) ~[?:?]
        at com.google.api.client.http.javanet.NetHttpRequest.execute(NetHttpRequest.java:93) ~[?:?]
        at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:981) ~[?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]

If i navigate to DDF in a browser,  the new certificate shows up, and has the root certificate. So DDF is picking up the new keystore ok.  However i then get the following stack trace:

HTTP ERROR 500

Problem accessing /. Reason:

    Server Error

Caused by:

javax.servlet.ServletException: IdP metadata is missing. No IDPSSODescriptor present.
	at org.codice.ddf.security.idp.client.IdpHandler.doHttpRedirectBinding(IdpHandler.java:451)
	at org.codice.ddf.security.idp.client.IdpHandler.getNormalizedToken(IdpHandler.java:283)
	at Proxyfadff37b_3702_4861_817c_7b8a63d161b1.getNormalizedToken(Unknown Source)
	at org.codice.ddf.security.filter.websso.WebSSOFilter.handleRequest(WebSSOFilter.java:145)
	at org.codice.ddf.security.filter.websso.WebSSOFilter.doFilter(WebSSOFilter.java:122)
	at org.codice.ddf.platform.filter.delegate.ProxyFilterChain.doFilter(ProxyFilterChain.java:91)
	at org.codice.ddf.platform.filter.delegate.DelegateServletFilter.doFilter(DelegateServletFilter.java:119)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
	at org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:205)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:284)
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
	at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
	at org.eclipse.jetty.server.Server.handle(Server.java:534)
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:333)
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
	at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:251)
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
	at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
	at java.lang.Thread.run(Thread.java:748)

effectively the only change from the initial working system is to point DDF at the new keystore which contains the externally generated key, cert, and a reference to the root cert.  
I've confirmed it does have all these, and that the truststore also has the new root cert entry

Any ideas what i'm missing?

Michael O'Connor

unread,
Aug 23, 2018, 8:40:16 AM8/23/18
to ddf-users
Hi,


When you created your certs, keys, keystore, etc did you use a separate key password from the keystore password? 
I think you may see this issue in that situation since I'm pretty sure that DDF doesn't have a setting for using a separate key password.
If you did use differing store and key passwords try changing one to match the other and see if that yields a different result.

V/R
Mike O'Connor

dmc...@gmail.com

unread,
Aug 23, 2018, 11:42:42 AM8/23/18
to ddf-users
Hi Mike,

i've double checked and i'm using the same password for the key and the keystore.

I'm using the following scripting  (items in {{}} are script variables):

openssl pkcs12 -export -in {{Cert}} -inkey {{Key}} -certfile {{cacert}} -name {{fqdn}} -out {{KeystorePkcs12}} -passout pass:{{KeystorePwd}}

keytool -importkeystore -srckeystore {{KeystorePkcs12}} -srcstorepass {{KeystorePwd}} -srcstoretype pkcs12  -destkeypass {{KeystorePwd}} -destkeystore {{KeystoreJKS}} -deststoretype jks -deststorepass {{KeystorePwd}} -noprompt

keytool -import -trustcacerts -alias {{caserver}} -file {{cacert}} -keystore {{KeystoreJKS}} -storepass {{KeystorePwd}} -noprompt

and to import to the truststore:

keytool -import -trustcacerts -alias {{caserver}} -file {{cacert}} -keystore {{Truststore}} -storepass {{KeystorePwd}} -noprompt

Can you see anything wrong with that?  

if i revert to the keystore as generated by certnew.sh using the ddf demo ca then DDF springs into life, so there's nothing fundamentally wrong with my DDF setup.
Reply all
Reply to author
Forward
0 new messages