Thanks, I'll try to increase the mentioned log levels. I'm on JDK 8 but I have a hard time believing it makes a difference

I'm getting a

10:04:39,186 DEBUG [io.undertow.request.io] (default I/O-8) UT005013: An IOException occurred: java.io.IOException: javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
  at io.undertow.protocols.ssl.SslConduit.notifyReadClosed(SslConduit.java:577)
  at io.undertow.protocols.ssl.SslConduit.doUnwrap(SslConduit.java:668)
  at io.undertow.protocols.ssl.SslConduit.doHandshake(SslConduit.java:608)
  at io.undertow.protocols.ssl.SslConduit.access$600(SslConduit.java:63)
  at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1034)
  at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:88)
  at org.xnio.nio.WorkerThread.run(WorkerThread.java:559)
Caused by: javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
  at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
  at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1646)
  at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1614)
  at sun.security.ssl.SSLEngineImpl.closeInbound(SSLEngineImpl.java:1541)
  at io.undertow.protocols.ssl.SslConduit.notifyReadClosed(SslConduit.java:575)
  ... 6 more


10:04:39,187 TRACE [org.xnio.safe-close] (default I/O-8) Closing resource org.xnio.nio.NioSocketStreamConnection@3e63b626
10:04:39,187 TRACE [org.xnio.nio] (default I/O-8) Cancelling key sun.nio.ch.SelectionKeyImpl@10301045 of java.nio.channels.SocketChannel[connected ishut local=/127.0.0.1:8443 remote=/127.0.0.1:50530] (same thread)
10:04:39,188 TRACE [org.xnio.listener] (default I/O-8) Invoking listener io.undertow.server.AbstractServerConnection$CloseSetter@22446ea6 on channel io.undertow.protocols.ssl.UndertowSslConnection@81e77d4
10:04:39,188 DEBUG [io.undertow.request] (default I/O-8) UT005013: An IOException occurred: java.nio.channels.ClosedChannelException
  at io.undertow.protocols.ssl.SslConduit.doWrap(SslConduit.java:783)
  at io.undertow.protocols.ssl.SslConduit.doHandshake(SslConduit.java:609)
  at io.undertow.protocols.ssl.SslConduit.access$600(SslConduit.java:63)
  at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1034)
  at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:88)
  at org.xnio.nio.WorkerThread.run(WorkerThread.java:559)

The whole scenario is that I'm trying to authenticate with a SmartCard. The card itself is working (tested on the manufacturer test site). So far I've

* Generated a keystore for the HTTPS listener

* Defined

                <https-listener name="https" verify-client="REQUIRED" security-realm="OSTiRealm" socket-binding="https"/>

and

            <security-realm name="OSTiRealm">
                <server-identities>
                    <ssl>
                        <keystore path="server.keystore" relative-to="jboss.server.config.dir" keystore-password="keypassword" key-password="keypassword"/>
                    </ssl>
                </server-identities>
            </security-realm>

If I take out the verify-client, I can access the HTTPS 8443 just fine (with the standard certificate complaint) but with verify-client on it's no go. I would have expected at least the client-side dialog for picking of certificate to authenticate with to appear. Or is the self-signed server certificate a problem?

Update. Nope, the problem persists even after I import the server certificate into Chrome

Just accessing the 8443 shouldn't need any client keystores and domains yet? Or do I have to export the certificate from the SmartCard and import it to some keystore? I'm a bit confused as this is my first venture into this area

Well, I got around five kilorows of text ;-)

(in the tutorial, I assume the <authentication> must be inside the realm?)

I'm a bit confused about the client store. At the point where the tutorial says you can test the SSL and you will be asked to trust the certificate. Client-authentication is required but the import of the client cert into the browser hasn't yet be done. Alternatively, shouldn't my client pop up a list of certificates which could be used for the auhtentication?

Thanks for the help,

Nik

Pardon my n00bishness but I noticed that the SmartCard client has installed two certificates into the client (one for login and one for signing). Should I export the one used for login into the client truststore?

Thanks in advance,

Nik

Did a fresh start in a VirtualBoxed Linux. This time I imported the root and user certificates that the SmartCard client had installed in Firefox and they went into the client truststore without problems. I also have accepted the self-signed certificate so that FireFox is OK with it. Still, when I access the page I get the attached log which boils down to

07:15:56,019 INFO  [stdout] (default task-2) *** Certificate chain
07:15:56,021 INFO  [stdout] (default task-2) <Empty>
07:15:56,021 INFO  [stdout] (default task-2) ***
07:15:56,022 INFO  [stdout] (default task-2) default task-2, fatal error: 42: null cert chain
07:15:56,028 INFO  [stdout] (default task-2) javax.net.ssl.SSLHandshakeException: null cert chain
07:15:56,028 INFO  [stdout] (default task-2) %% Invalidated:  [Session-1, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]
07:15:56,028 INFO  [stdout] (default task-2) default task-2, SEND TLSv1.2 ALERT:  fatal, description = bad_certificate
07:15:56,028 INFO  [stdout] (default task-2) default task-2, WRITE: TLSv1.2 Alert, length = 2

I am bit at loss *which* certificate is bad since everything was imported fine.

Thanks in advance,

  Nik

I got it to work! I pretty much imported every certificate they SmartCard provider had on their list. Apparently they were not quite the same as the exported certificates.

Thanks for your help!