WARN org.eclipse.jetty.io.nio - javax.net.ssl.SSLException: Received fatal alert: certificate_unknown log messages

Summary

It may be noticed that virtually every https:// request into repository manager 2 causes a WARN level log message containing the following text:

WARN org.eclipse.jetty.io.nio - javax.net.ssl.SSLException: Received fatal alert: certificate_unknown

Cause

This problem should only happen if you have NXRM 2 configured with direct TLS Connector configuration.

What appears to trigger this is a server certificate with a Owner value that refers to a non host-name value in the last distinguished name part where a host name is usually specified:

For example a self-signed certificate created with the following command will reproduced the WARN messages for secure inbound requests:

keytool -genkeypair -v -keystore nexus-rm-server-inbound.p12 -storepass password -keypass password -storetype PKCS12 \
-alias nexus-rm-server -keyalg RSA -validity 356 -ext 'EKU=serverAuth' \
-ext 'SAN=DNS:nexus.example.com,DNS:repository.example.com,DNS:iq.example.com' \
-dname 'EMAILADDRESS=fake@@example.com, CN=nexus.example.com, OU=Example, O=Example Group, L=Chicago, ST=Illinois, C=US'

The EMAILADDRESS=fake@@example.com part of the dname causes this.

Example stack traces from 2.14.15 where this happens when the org.eclipse.jetty.io.nio logger level is set to trace:

2019-12-23 15:19:59,131-0400 DEBUG [qtp773269986-80]  org.eclipse.jetty.io.nio.ssl - SCEP@2e58d356{l(/127.0.0.1:58943)<->r(/127.0.0.1:8443),s=1,open=true,ishut=false,oshut=false,rb=false,wb=false,w=true,i=0r}-{SslConnection@3b81ae03 SSL NEED_UNWRAP i/o/u=7/0/0 ishut=false oshut=false {AsyncHttpConnection@1b9e9f93,g=HttpGenerator{s=0,h=-1,b=-1,c=-1},p=HttpParser{s=-14,l=0,c=0},r=0}}
javax.net.ssl.SSLException: Received fatal alert: certificate_unknown
 at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
 at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1647)
 at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1615)
 at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1781)
 at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:1070)
 at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:896)
 at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:766)
 at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
 at org.eclipse.jetty.io.nio.SslConnection.unwrap(SslConnection.java:536)
 at org.eclipse.jetty.io.nio.SslConnection.process(SslConnection.java:401)
 at org.eclipse.jetty.io.nio.SslConnection.access$900(SslConnection.java:48)
 at org.eclipse.jetty.io.nio.SslConnection$SslEndPoint.fill(SslConnection.java:678)
 at org.eclipse.jetty.http.HttpParser.fill(HttpParser.java:1044)
 at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:280)
 at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
 at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
 at org.eclipse.jetty.io.nio.SslConnection.handle(SslConnection.java:196)
 at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
 at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
 at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
 at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
 at java.lang.Thread.run(Thread.java:748)

2019-12-23 15:19:59,132-0400 DEBUG [qtp773269986-80]  org.eclipse.jetty.io.nio.ChannelEndPoint - close SCEP@2e58d356{l(/127.0.0.1:58943)<->r(/127.0.0.1:8443),s=1,open=true,ishut=false,oshut=false,rb=false,wb=false,w=true,i=0r}-{SslConnection@3b81ae03 SSL NEED_UNWRAP i/o/u=7/0/0 ishut=false oshut=false {AsyncHttpConnection@1b9e9f93,g=HttpGenerator{s=0,h=-1,b=-1,c=-1},p=HttpParser{s=-14,l=0,c=0},r=0}}
2019-12-23 15:19:59,135-0400 DEBUG [qtp773269986-80]  org.eclipse.jetty.io.nio - EOForg.eclipse.jetty.io.EofException: null
 at org.eclipse.jetty.http.HttpParser.fill(HttpParser.java:1050)
 at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:280)
 at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
 at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
 at org.eclipse.jetty.io.nio.SslConnection.handle(SslConnection.java:196)
 at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
 at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
 at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
 at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
 at java.lang.Thread.run(Thread.java:748)
Caused by: javax.net.ssl.SSLException: Received fatal alert: certificate_unknown
 at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
 at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1647)
 at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1615)
 at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1781)
 at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:1070)
 at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:896)
 at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:766)
 at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
 at org.eclipse.jetty.io.nio.SslConnection.unwrap(SslConnection.java:536)
 at org.eclipse.jetty.io.nio.SslConnection.process(SslConnection.java:401)
 at org.eclipse.jetty.io.nio.SslConnection.access$900(SslConnection.java:48)
 at org.eclipse.jetty.io.nio.SslConnection$SslEndPoint.fill(SslConnection.java:678)
 at org.eclipse.jetty.http.HttpParser.fill(HttpParser.java:1044)
 ... 9 common frames omitted

Solution

NXRM 2 uses older versions of Eclipse Jetty 8 which causes this issue.

A Jira issue NEXUS-21370 has been filed upgrade NXRM 2 to use Eclipse Jetty 9 which would avoid this issue. Please upgrade to at least the fixVersion of that issue.

NXRM 3 uses the latest version of Jetty 9, which will also avoid this issue if you upgrade from NXRM 2 and reuse the same server certificate.

Otherwise creating a server certificate with a host name in the DN will avoid this issue. For example, this works:

keytool -genkeypair -v -keystore nexus-rm-server-inbound.p12 -storepass password -keypass password -storetype PKCS12 \
-alias nexus-rm-server -keyalg RSA -validity 356 -ext 'EKU=serverAuth' \
-ext 'SAN=DNS:nexus.example.com,DNS:repository.example.com,DNS:iq.example.com' \
-dname 'CN=nexus.example.com, OU=Example, O=Example Group, L=Chicago, ST=Illinois, C=US'

 Because CN=nexus.example.com refers to a valid host name, the log message is avoided.

 

Have more questions? Submit a request

0 Comments

Article is closed for comments.