Jetty 9.3 SSL Keystore Path and SOAP Backchannel Errors

Tue Aug 18 11:49:12 EDT 2015

Greetings All,

I'm currently in the midst of building-out a lab IdPv3 server for my institution, en route to replacing our production IdPv2 servers, and have encountered a couple of stumbling blocks along the way, both of which relate to SSL/TLS configuration and Jetty.

I am using Jetty 9.3.2.v20150730, Shibboleth Identity Provider 3.1.2, and Java 8u51, on Windows. I am not using the Shib-provided Jetty container, but have exactly followed the instructions provided at https://wiki.shibboleth.net/confluence/display/IDP30/Jetty93.

My first issue is that when I attempt to start Jetty, it logs a warning and exits immediately, indicating that a required keystore file is missing. Verbatim error message follows:

WARNING: Missing Required File: ${jetty.base}\etc\keystore
WARNING:   Can be downloaded From: http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/plain/jetty-server/src/test/config/etc/keystore?id=master
WARNING:   Run start.jar --create-files to download
INFO: Base directory was modified

I have already specified the absolute path to this keystore file in JETTY_BASE/start.d/ssl.ini with the jetty.sslContext.keyStorePath property.

It appears that this is happening because the ssl.mod file included in JETTY_HOME/modules includes a [files] stanza that (naively) requires the keystore to be located at a particular path:

[files]
http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/plain/jetty-server/src/test/config/etc/keystore?id=${jetty.tag.version}|etc/keystore<http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/plain/jetty-server/src/test/config/etc/keystore?id=$%7bjetty.tag.version%7d|etc/keystore>

I found a Jetty bug related to this particular issue (https://bugs.eclipse.org/bugs/show_bug.cgi?id=434880) which they claim to have resolved, but I'm nevertheless still seeing Jetty exit.

Have others of you encountered this issue? Am I missing something here, or ought I just go ahead and open a bug report with Jetty about this?

In the meantime, this can be worked around by putting a copy of ssl.mod into JETTY_BASE/modules and removing the [files] stanza. If this is indeed an actual issue, and sounds like an appropriate workaround, I'll update the Jetty93 documentation on the Shib wiki accordingly.

My second issue relates to SOAP Backchannel configuration. Once again, I have followed the instructions specified at https://wiki.shibboleth.net/confluence/display/IDP30/Jetty93. After solving the previous issue, upon trying to start Jetty, I see the following error in my logs:

                jetty.log
                ----------
10:40:09.456 - INFO [org.eclipse.jetty.util.log:186] - Logging initialized @338ms
10:40:09.534 - INFO [org.eclipse.jetty.util.log:-2] - Redirecting stderr/stdout to C:\Program Files\Jetty\shibboleth-base\logs\2015_08_18.stderrout.log
10:40:09.627 - WARN [org.eclipse.jetty.xml.XmlConfiguration:449] - Config error at <Set name="IncludeCipherSuites">
      <Array type="String">
          <Item>TLS_ECDHE.*</Item>
          <Item>TLS_RSA.*</Item>
      </Array>
    </Set>
10:40:09.627 - WARN [org.eclipse.jetty.xml.XmlConfiguration:449] - Config error at <New id="shibContextFactory" class="net.shibboleth.utilities.jetty9.DelegateToApplicationSslContextFactory">
    <Set name="KeyStorePath"><Property name="jetty.backchannel.sslContext.keyStorePath"/></Set>
    <Set name="KeyStoreType"><Property name="jetty.backchannel.sslContext.keyStoreType"/></Set>
    <Set name="KeyStorePassword"><Property name="jetty.backchannel.sslContext.keyStorePassword"/></Set>

    <Set name="TrustStoreType"><Property name="jetty.backchannel.sslContext.keyStoreType"/></Set>
    <Set name="EndpointIdentificationAlgorithm"/>
    <Set name="renegotiationAllowed">false</Set>
    <Set name="useCipherSuitesOrder">true</Set>
    <Set name="IncludeCipherSuites">
      <Array type="String">
          <Item>TLS_ECDHE.*</Item>
          <Item>TLS_RSA.*</Item>
      </Array>
    </Set>
    <Set name="ExcludeCipherSuites">
      <Array type="String">
        <Item>.*NULL.*</Item>
        <Item>.*RC4.*</Item>
        <Item>.*MD5.*</Item>
        <Item>.*DES.*</Item>
        <Item>.*DSS.*</Item>
      </Array>
    </Set>
  </New>

2015_08_18.stderrout.log
-------------------------------
Exception in thread "main" java.lang.NoSuchMethodException: class net.shibboleth.utilities.jetty9.DelegateToApplicationSslContextFactory.setIncludeCipherSuites(class java.lang.String)
                at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.set(XmlConfiguration.java:591)
                at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:411)
                at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.newObj(XmlConfiguration.java:799)
                at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:423)
                at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:358)
                at org.eclipse.jetty.xml.XmlConfiguration.configure(XmlConfiguration.java:259)
                at org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1498)
                at java.security.AccessController.doPrivileged(Native Method)
                at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1435)

I've looked at both the code<http://svn.shibboleth.net/view/utilities/jetty9-dta-ssl/trunk/src/main/java/net/shibboleth/utilities/jetty9/DelegateToApplicationSslContextFactory.java?revision=396&view=markup> for net.shibboleth.utilities.jetty9.DelegateToApplicationSslContextFactory, as well as the relevant Eclipse documentation<http://download.eclipse.org/jetty/stable-9/apidocs/org/eclipse/jetty/util/ssl/SslContextFactory.html>, and can't seem to quite figure out why this is happening.

Since net.shibboleth.utilities.jetty9.DelegateToApplicationSslContextFactory extends org.eclipse.jetty.util.ssl.SslContextFactory (where the method setIncludeCipherSuites is defined) this error ought not to occur, unless the object isn't getting initialized properly, the parent Jetty class has changed, or some earlier exception is occurring and not getting handled.

I noticed Scott's note on a previous version of the Jetty93 wiki page indicating that the back channel configuration was largely untested, so I suppose my question is, is this still the case? If not, is there something that I'm missing, or did the Jetty SSL refactoring have further implications than the ones which have been commented upon in previous threads?

Thanks in advance for any advice / insight, and I'm happy to provide more information and do more digging as necessary.

Michael Domingues
Systems Administrator
Directory and Authentication Services, AIS, ITS
University of Iowa

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150818/2106a938/attachment-0001.html>