Re: Vulnerability flagged in Nessus Scan

[John Palmer]

As the concern is that an erro page will show the tomcat version/patch info
AND a stacktrace,\
I found the easier/better? solution to be adding . showReport="false"
showServerInfo="false"
to the Error Report Valve section at the bottom of server.xml (and addin or
or uncommenting that valve section...):

 

On Wed, Jun 3, 2020 at 5:40 AM Martin Grigorov  wrote:

> On Wed, Jun 3, 2020 at 11:14 AM FANG YAP  wrote:
>
> > Hello Martin,
> >
> > It is to say that I have to declare something like this in web.xml file?
> >
> > 
> > java.lang.Exception
> > /error.jsp
> >
>
> Better use the error-code ones from the StackOverflow link I gave you.
> Your approach will cover only error code 500 (for Exceptions, but not for
> java.lang.Error) and won't cover NotFound (404) and the others.
> I guess Nessus won't be totally happy with your approach.
>
>
> >
> > Regards with Thanks,
> >
> > Fang
> >
> > On Wed, 3 Jun 2020, 15:56 Martin Grigorov,  wrote:
> >
> > > Hi,
> > >
> > > On Wed, Jun 3, 2020 at 5:53 AM FANG YAP  wrote:
> > >
> > > > Resend
> > > >
> > > > On Wed, 3 Jun 2020, 10:10 FANG YAP,  wrote:
> > > >
> > > > > Hi Tomcat,
> > > > >
> > > > > Nessus scanned and found issue in Apache Tomcat Port 8080
> > > > >
> > > > > Port: 8080
> > > > > Plugin Text:
> > > > > The server is not configured to return a custom page in the event
> of
> > a
> > > > > client requesting a non-existent resource. This may result in a
> > > potential
> > > > > disclosure of sensitive information about the server to attacker.
> > > > >
> > > > > Apache Tomcat Version: 8.5.43
> > > > > JDK 8: 1.8.0_212 (Will be upgrading to latest soon to latest
> > 1.8.0_251)
> > > >
> > >
> > > To configure custom error pages and thus to suppress this issue you
> can:
> > > 1) use ErrorReportValve
> > > <
> > >
> >
> https://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#Error_Report_Valve
> > > >
> > >
> > > 2) configure error-page elements in your application web.xml -
> > > https://stackoverflow.com/a/7066536/497381
> > >
> > >
> > > > >
> > > > > Your assistance would be greatly appreciated
> > > > >
> > > > > Rgs,
> > > > > Fang
> > > > >
> > > >
> > >
> >
>

how to enable OCSP revocation checking from tomcat 8.5.x using NIO2 w OpenSSL ?

[John Palmer]

What, if anything, needs to be configured to ENABLE (preferably REQUIRE)
tomat to do CLIENT certificate revocation checking via OCSP in Tomcat
8.5.38 using Openssl ?
(will this work with NIO2 ? )

1) using Openssl (the tc-native-1.dll binary for Windows, compiled w OCSP
support - the X64 dll from
tomcat-native-1.2.21-openssl-1.1.1a-ocsp-win32-bin.zip
(i'd prefer to have this working with OpenSSl for a couple of reasons).

2) using JSSE (java 8 (1.8.0_202)) with the NIO2 connector
(I've tried adding -Dcom.sun.net.ssl.checkRevocation=true to the Java
options for the tomat service).


I can't see anything indicating OCSP checks in the logs for either.
(logs do indicate the OpenSSL

for JSSE, by adding -Djavax.net.debug=ssl to the Java Options for the
tomcat service I see logging for key & trust stores being loaded, etc. in
tomcat8-stdout(date).log
the server requesting a client cert, the Client cert being received and
finding a trusted root for it ("Found trusted certificate:"),
but nothing about revocation checking
(I do see:
check handshake state: certificate_verify[15]
update handshake state: certificate_verify[15]

but I'm not sure that's revocation checking...).

for OpenSLL, I'mnot sure how to enable equivalent loggingby enabling
pretty much ALL the logging
org.apache.coyote.http2.level=ALL
org.apache.level=ALL
org.apache.catalina.session.level=ALL
I can see the truststore ("Added client CA cert") being loaded but not much
else about certificates.


Wireshark shows me OCSP calls for the SERVER cert, presumable from the
browswer (fireFox).
(I'm testing this on a personal computer, tomcat and browser on the same
computer).
If there are equivalent OCSP calls for the CLIENT cert, I'm not seeing them.


the Connector part of the server xml.config file is (ip address and server
name etc removed):

 

Re: how to enable OCSP for Tomcat w OpenSSL

[John Palmer]

ecurity.provider.certpath.PKIXCertPathValidator.engineValidate(Unknown
Source)
at java.security.cert.CertPathValidator.validate(Unknown Source)
... 26 more
Caused by: java.security.cert.CertPathValidatorException: Could not
determine revocation status
at
sun.security.provider.certpath.RevocationChecker.buildToNewKey(Unknown
Source)
at
sun.security.provider.certpath.RevocationChecker.verifyWithSeparateSigningKey(Unknown
Source)
at sun.security.provider.certpath.RevocationChecker.checkCRLs(Unknown
Source)
at sun.security.provider.certpath.RevocationChecker.checkCRLs(Unknown
Source)
at sun.security.provider.certpath.RevocationChecker.check(Unknown
Source)
at sun.security.provider.certpath.RevocationChecker.check(Unknown
Source)
... 31 more

16-Apr-2019 16:59:14.540 FINE [https-openssl-nio2-a.b.c.d-443-exec-7]
org.apache.tomcat.util.net.openssl.OpenSSLEngine.checkLastError OpenSSL
error: [337100934] message: [error:1417C086:SSL
routines:tls_process_client_certificate:certificate verify failed]


the Connector part of the server xml.config file is (ip address and server
name etc removed):

 

    
    




On Thu, Apr 4, 2019 at 7:47 PM John Palmer  wrote:

> Well, after much research and experimentation I got OCSP working with the
> JSSE  flaovor, NIO2 connector (renamed the OCSP-enabled tc-native-1.dll so
> it isn't used and JSSE is used instead).
>
> 2 things had to be set:
> 1: server.xml: add to the SSLHostConfig section (inside the Connector
> section)
> revocationEnabled="true"
> certificateVerification="require"
>
> 2:  java.security file in the (java)\jre\lib\security folder:
> uncomment the line:ocsp.enable=true
> (you get a "can't connect securely to this page" in IE if you forget.)
> (if there's a way to do this with the Java options used by the tomcat
> service(eg -D(something)ocsp.enable="true", I'd appreciate someone
> telling me).
>
> by adding -Djava.security.debug="certpath ocsp"  to the Java options used
> by the tomcat service (Windows)... I have logging showing the OCSP checking
> etc
> and wireshark shows me the OCSP calls (there MAY be some caching being
> done by the java (or possibly Windows CAPI) code, not all the expected OSCP
> requests seem to always be there).
>
> by restoring the NON-OCSP-enabled tc-native-1.dll, I found that the same
> settings allow the same java calls to work the same way
>
> and by restoring the OCSP-enabled tc-native-1.dll... those still work.
>
> Apparently there is some OTHER setting or configuration needed for the
> OCSP-enabled tc-native-1.dll to work... and I haven't found it yet.
>
> I'm trying to understand from the tc-native source what I might be
> missing, but apparently I'm overlooking it.
>
>
> helpful suggestions are welcomed.
>
> On Wed, Apr 3, 2019 at 12:32 PM John Palmer  wrote:
>
>> I appreciate your response
>>
>> > Setting `certificateVerification="require"` on your Connector
>>
>> I changed
>>   `certificateVerification="REQUIRED"
>> to
>>   `certificateVerification="require"`
>>
>> still not seeing any OCSP calls in wireshark for this
>>
>> I did find out how to enable logging better  (by adding either of these
>> to logging.properties):
>> org.apache.tomcat.util.net.openssl.level=ALL
>> org.apache.tomcat.util.net.level=ALL
>>
>> and I can see logs confirming  that the trust store is being used:
>> OpenSSLContext.init Added client CA cert:...) ;
>>
>> with logging set to org.apache.tomcat.level=ALL
>> I see confirmation that the certificateVerification is being parsed,
>> apparently correctly.
>>
>> but I still don't see any evidence in the tomcat/catlina logs or in
>> wireshark  that anything is happening to accomplish this.
>>
>>
>>
>> On Tue, Apr 2, 2019 at 3:47 PM Coty Sutherland 
>> wrote:
>>
>>> Hi,
>>>
>>> On Mon, Apr 1, 2019 at 3:30 PM John Palmer 
>>> wrote:
>>>
>>> > What, if anything, needs to be configured to ENABLE (preferably
>>> REQUIRE)
>>> > tomat to do CLIENT certificate revocation checking via OCSP in Tomcat
>>> > 8.5.38 using Openssl ?
>>>
>>>
>>> Setting `certificateVerification="require"` on your Connector and using a
>>> client certificate that has an OCSP URI should be it. See
>>>
>>> https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html#Using_OCSP_Certificates
>>> for more information on how to configure it.
>>>
>>>
>>> >
>>&g

Re: how to enable OCSP for Tomcat w OpenSSL

[John Palmer]

Well, after much research and experimentation I got OCSP working with the
JSSE  flaovor, NIO2 connector (renamed the OCSP-enabled tc-native-1.dll so
it isn't used and JSSE is used instead).

2 things had to be set:
1: server.xml: add to the SSLHostConfig section (inside the Connector
section)
revocationEnabled="true"
certificateVerification="require"

2:  java.security file in the (java)\jre\lib\security folder:
uncomment the line:ocsp.enable=true
(you get a "can't connect securely to this page" in IE if you forget.)
(if there's a way to do this with the Java options used by the tomcat
service(eg -D(something)ocsp.enable="true", I'd appreciate someone telling
me).

by adding -Djava.security.debug="certpath ocsp"  to the Java options used
by the tomcat service (Windows)... I have logging showing the OCSP checking
etc
and wireshark shows me the OCSP calls (there MAY be some caching being done
by the java (or possibly Windows CAPI) code, not all the expected OSCP
requests seem to always be there).

by restoring the NON-OCSP-enabled tc-native-1.dll, I found that the same
settings allow the same java calls to work the same way

and by restoring the OCSP-enabled tc-native-1.dll... those still work.

Apparently there is some OTHER setting or configuration needed for the
OCSP-enabled tc-native-1.dll to work... and I haven't found it yet.

I'm trying to understand from the tc-native source what I might be missing,
but apparently I'm overlooking it.


helpful suggestions are welcomed.

On Wed, Apr 3, 2019 at 12:32 PM John Palmer  wrote:

> I appreciate your response
>
> > Setting `certificateVerification="require"` on your Connector
>
> I changed
>   `certificateVerification="REQUIRED"
> to
>   `certificateVerification="require"`
>
> still not seeing any OCSP calls in wireshark for this
>
> I did find out how to enable logging better  (by adding either of these to
> logging.properties):
> org.apache.tomcat.util.net.openssl.level=ALL
> org.apache.tomcat.util.net.level=ALL
>
> and I can see logs confirming  that the trust store is being used:
> OpenSSLContext.init Added client CA cert:...) ;
>
> with logging set to org.apache.tomcat.level=ALL
> I see confirmation that the certificateVerification is being parsed,
> apparently correctly.
>
> but I still don't see any evidence in the tomcat/catlina logs or in
> wireshark  that anything is happening to accomplish this.
>
>
>
> On Tue, Apr 2, 2019 at 3:47 PM Coty Sutherland 
> wrote:
>
>> Hi,
>>
>> On Mon, Apr 1, 2019 at 3:30 PM John Palmer  wrote:
>>
>> > What, if anything, needs to be configured to ENABLE (preferably REQUIRE)
>> > tomat to do CLIENT certificate revocation checking via OCSP in Tomcat
>> > 8.5.38 using Openssl ?
>>
>>
>> Setting `certificateVerification="require"` on your Connector and using a
>> client certificate that has an OCSP URI should be it. See
>>
>> https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html#Using_OCSP_Certificates
>> for more information on how to configure it.
>>
>>
>> >
>>
>>
>> > I'm sure I'm missing something simple and obvious (once pointed out) but
>> > I've been struggling with this all morning).
>> >
>> > 1) using Openssl (the tc-native-1.dll binary for Windows, compiled w
>> OCSP
>> > support - the X64 dll from
>> > tomcat-native-1.2.21-openssl-1.1.1a-ocsp-win32-bin.zip)
>> > (will this even work with NIO2 ? - I don't HAVE to use NIO2)
>> >
>>
>> It will work, but only if you're using the openssl implementation.
>>
>>
>> > (i'd prefer to have this working with OpenSSl for a couple of reasons).
>> > (extra points for a configuration to allow it to use Axways (formerly
>> > Tumbleweed) Desktop Validator for its OCSP-caching features).
>> >
>> > 2) using JSSE (java 8 (1.8.0_202)) with the NIO2 connector
>> > (I've tried adding -Dcom.sun.net.ssl.checkRevocation=true to the Java
>> > options for the tomat service).
>> >
>> >
>> > I can't see anything indicating OCSP checks in the logs for either.
>> >
>>
>> There isn't any OCSP code in Tomcat and tomcat-native doesn't log much of
>> anything when it's in use, so there's not much indication that it's
>> working
>> there.
>>
>>
>> >
>> > (when the tc-native-1.dll is present, the logs show it being used:
>> > INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
>> > Loaded APR based Apache Tomcat Native library [1.2.21] using AP

Re: how to enable OCSP for Tomcat w OpenSSL

[John Palmer]

I appreciate your response

> Setting `certificateVerification="require"` on your Connector

I changed
  `certificateVerification="REQUIRED"
to
  `certificateVerification="require"`

still not seeing any OCSP calls in wireshark for this

I did find out how to enable logging better  (by adding either of these to
logging.properties):
org.apache.tomcat.util.net.openssl.level=ALL
org.apache.tomcat.util.net.level=ALL

and I can see logs confirming  that the trust store is being used:
OpenSSLContext.init Added client CA cert:...) ;

with logging set to org.apache.tomcat.level=ALL
I see confirmation that the certificateVerification is being parsed,
apparently correctly.

but I still don't see any evidence in the tomcat/catlina logs or in
wireshark  that anything is happening to accomplish this.



On Tue, Apr 2, 2019 at 3:47 PM Coty Sutherland  wrote:

> Hi,
>
> On Mon, Apr 1, 2019 at 3:30 PM John Palmer  wrote:
>
> > What, if anything, needs to be configured to ENABLE (preferably REQUIRE)
> > tomat to do CLIENT certificate revocation checking via OCSP in Tomcat
> > 8.5.38 using Openssl ?
>
>
> Setting `certificateVerification="require"` on your Connector and using a
> client certificate that has an OCSP URI should be it. See
>
> https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html#Using_OCSP_Certificates
> for more information on how to configure it.
>
>
> >
>
>
> > I'm sure I'm missing something simple and obvious (once pointed out) but
> > I've been struggling with this all morning).
> >
> > 1) using Openssl (the tc-native-1.dll binary for Windows, compiled w OCSP
> > support - the X64 dll from
> > tomcat-native-1.2.21-openssl-1.1.1a-ocsp-win32-bin.zip)
> > (will this even work with NIO2 ? - I don't HAVE to use NIO2)
> >
>
> It will work, but only if you're using the openssl implementation.
>
>
> > (i'd prefer to have this working with OpenSSl for a couple of reasons).
> > (extra points for a configuration to allow it to use Axways (formerly
> > Tumbleweed) Desktop Validator for its OCSP-caching features).
> >
> > 2) using JSSE (java 8 (1.8.0_202)) with the NIO2 connector
> > (I've tried adding -Dcom.sun.net.ssl.checkRevocation=true to the Java
> > options for the tomat service).
> >
> >
> > I can't see anything indicating OCSP checks in the logs for either.
> >
>
> There isn't any OCSP code in Tomcat and tomcat-native doesn't log much of
> anything when it's in use, so there's not much indication that it's working
> there.
>
>
> >
> > (when the tc-native-1.dll is present, the logs show it being used:
> > INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
> > Loaded APR based Apache Tomcat Native library [1.2.21] using APR version
> > [1.6.5].
> > INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
> > APR capabilities: IPv6 [true], sendfile [true], accept filters [false],
> > random [true].
> > INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
> > APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true]
> > INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL
> > OpenSSL successfully initialized [OpenSSL 1.1.1a  20 Nov 2018]
> > INFO [main]
> > org.apache.coyote.http11.AbstractHttp11Protocol.configureUpgradeProtocol
> > The ["https-openssl-nio2-192.168.1.16-443"] connector has been configured
> > to support negotiation to [h2] via ALPN
> > INFO [main] org.apache.coyote.AbstractProtocol.init Initializing
> > ProtocolHandler ["https-openssl-nio2-192.168.1.16-443"]
> > )
> >
> >
> > for JSSE, by adding -Djavax.net.debug=ssl to the Java Options for the
> > tomcat service I see logging for key & trust stores being loaded, etc. in
> > tomcat8-stdout(date).log
> > the server requesting a client cert, the Client cert being received and
> > finding a trusted root for it ("Found trusted certificate:"),
> > but nothing about revocation checking
> > (I do see:
> > check handshake state: certificate_verify[15]
> > update handshake state: certificate_verify[15]
> >
> > but I'm not sure that's revocation checking...).
> >
> > for OpenSLL, I'mnot sure how to enable equivalent loggingby enabling
> > pretty much ALL the logging
> > org.apache.coyote.http2.level=ALL
> > org.apache.level=ALL
> > org.apache.catalina.session.level=ALL
> > I can see the truststore ("Added client CA cert") being loaded but not
> much
> > else about certificates.
> >
> >
>

how to enable OCSP for Tomcat w OpenSSL

[John Palmer]

What, if anything, needs to be configured to ENABLE (preferably REQUIRE)
tomat to do CLIENT certificate revocation checking via OCSP in Tomcat
8.5.38 using Openssl ?

I'm sure I'm missing something simple and obvious (once pointed out) but
I've been struggling with this all morning).

1) using Openssl (the tc-native-1.dll binary for Windows, compiled w OCSP
support - the X64 dll from
tomcat-native-1.2.21-openssl-1.1.1a-ocsp-win32-bin.zip)
(will this even work with NIO2 ? - I don't HAVE to use NIO2)
(i'd prefer to have this working with OpenSSl for a couple of reasons).
(extra points for a configuration to allow it to use Axways (formerly
Tumbleweed) Desktop Validator for its OCSP-caching features).

2) using JSSE (java 8 (1.8.0_202)) with the NIO2 connector
(I've tried adding -Dcom.sun.net.ssl.checkRevocation=true to the Java
options for the tomat service).


I can't see anything indicating OCSP checks in the logs for either.

(when the tc-native-1.dll is present, the logs show it being used:
INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
Loaded APR based Apache Tomcat Native library [1.2.21] using APR version
[1.6.5].
INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
APR capabilities: IPv6 [true], sendfile [true], accept filters [false],
random [true].
INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true]
INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL
OpenSSL successfully initialized [OpenSSL 1.1.1a  20 Nov 2018]
INFO [main]
org.apache.coyote.http11.AbstractHttp11Protocol.configureUpgradeProtocol
The ["https-openssl-nio2-192.168.1.16-443"] connector has been configured
to support negotiation to [h2] via ALPN
INFO [main] org.apache.coyote.AbstractProtocol.init Initializing
ProtocolHandler ["https-openssl-nio2-192.168.1.16-443"]
)


for JSSE, by adding -Djavax.net.debug=ssl to the Java Options for the
tomcat service I see logging for key & trust stores being loaded, etc. in
tomcat8-stdout(date).log
the server requesting a client cert, the Client cert being received and
finding a trusted root for it ("Found trusted certificate:"),
but nothing about revocation checking
(I do see:
check handshake state: certificate_verify[15]
update handshake state: certificate_verify[15]

but I'm not sure that's revocation checking...).

for OpenSLL, I'mnot sure how to enable equivalent loggingby enabling
pretty much ALL the logging
org.apache.coyote.http2.level=ALL
org.apache.level=ALL
org.apache.catalina.session.level=ALL
I can see the truststore ("Added client CA cert") being loaded but not much
else about certificates.


Wireshark shows me OCSP calls for the SERVER cert, presumable from the
browswer (fireFox).
(I'm testing this on a personal computer, tomcat and browser on the same
computer).
If there are equivalent OCSP calls for the CLIENT cert, I'm not seeing them.


the Connector part of the server xml.config file is (ip address and server
name etc removed):

 

Re: Tomcat 9 Nio2+OpenSSL problem (very likely a bug)

[John Palmer]

I'm testing to see if this might be an issue on a new tomcat 8.5.38 upgrade
I'm doing  (using NIO2 and OpenSSL) before I promote this to our Production
environment  :)
(Windows Server 2008R2, Java (javaC.exe) version is 1.8.0_191)
.. after some missteps (had to add some imports to get it to compile, and
use the -Djavax.net.ssl.trustStore, ... .trustStoreType,
..trustStorePassword args when running...

4 successes. no connection resets.

import javax.net.ss.SSLSocket;
import javax.net.ss.SSLSocketFactory
import java.io.*;
import java.time.*;
import java.time.temporal.ChronoUnit;


On Wed, Mar 13, 2019 at 3:29 PM Igor T  wrote:

> Prerequisites:
> OS: Windows Server 2012 R2
> Java: checked on both jdk1.8.0_162 jdk1.8.0_181
> Tomcat: windows x64 builds checked on 9.0.12, 9.0.16, 9.0.17-dev
> Valid SSL certificates
> Content of file located at webapp/ROOT/1.txt: []
> Tomcat's connector settings:
> 
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>
> sslImplementationName="org.apache.tomcat.util.net
> .openssl.OpenSSLImplementation"
> connectionTimeout="5000"
> SSLEnabled="true"
> scheme="https"
> secure="true"
> >
>
> This configuration leads to 50% of the traffic to be rejected with
> Connection resets. First socket connects and receives the service, but
> every second is resetted.
>
> Exactly this combination leads to connection resets:
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> sslImplementationName="org.apache.tomcat.util.net
> .openssl.OpenSSLImplementation"
>
> Configurations that work well without connection resets:
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>
> sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
> or
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> sslImplementationName="org.apache.tomcat.util.net
> .openssl.OpenSSLImplementation"
>
> Java code to reproduce the connection resets (works well with any
> other secure server):
> (there is no resets if a variable named FIX__gotoSleepAfterHandshake =
> true)
>
> public class CheckConnectionResets{
> static String host = "your-test-host";
>
> public static void main( String[] args ) throws
> InterruptedException, IOException{
>
> SSLSocketFactory factory =
> (SSLSocketFactory)SSLSocketFactory.getDefault();
> int nRuns = 4;
> int success = 0;
> int denial = 0;
>
> boolean FIX__gotoSleepAfterHandshake = false;
>
> for( int i = 0; i < nRuns; i++ ){
> try ( SSLSocket socket = (SSLSocket)factory.createSocket(
> host, 443 ) ){
>
> if( FIX__gotoSleepAfterHandshake ){
> socket.startHandshake();
> Thread.sleep( 500 );
> }
> try ( PrintWriter out = new PrintWriter( new
> BufferedWriter( new OutputStreamWriter( socket.getOutputStream() ) )
> );
> InputStream is = socket.getInputStream(); ){
>
> out.println( "GET /1.txt HTTP/1.1" );
> out.println( "Host: " + host );
> out.println( "Accept: */*" );
> out.println();
> out.flush();
>
> if( out.checkError() ){
> System.out.println( "SSLSocketClient:
> java.io.PrintWriter error" );
> }
>
> Instant start = Instant.now();
> /* read full response */
> byte[] buff = new byte[ 1024 ];
> int read = is.read( buff );
> success++;
> System.out.println( "success: " + success + ",
> read " + read + " bytes for: " + start.until( Instant.now(),
> ChronoUnit.MILLIS ) + "ms" );
>
> } catch ( IOException e ) {
> denial++;
> System.err.println( "denial: " + denial + ", " +
> e.getMessage() );
> }
>
> Sample output:
> success: 1, read 73 bytes for: 78ms
> denial: 1, Connection reset
> success: 2, read 73 bytes for: 78ms
> denial: 2, Connection reset
>
> The bug is stable, and always reproducible.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: tomcat 8.5.37, Http11Nio2Protocol (OpenSSL), clientAuth or certificateVerification options

[John Palmer]

You're (both) quite right, my apologies.
(this is embarrassing)

In my defense, I've been bouncing back and forth between my personal
desktop machine (windows 10)
where I was having this issue...
and a development server, where this was working just fine.

While at lunch, it occurred to me to wonder if I had the same Tomcat and
TC-Native bits on each .. confirmed after lunch that these were different.
(tc-native 1.2.21 on the desktop, 1.2.19 on the server)
Changed those on my desktop to match those of the server, same issue...
compared the server.xml files and found that on the desktop, where I had
put back the older  (7.x) format Connector stuff and - (the mistake) - left
the clientAuth setting at "want" rather than "true".
corrected that, working as expected.

Went back to the OpenSSL Connector format and saw new errors...
(useServerCipherSuitesOrder="true" in the Connector section caused a
_default_hostConfig (something like that) error...PROBABLY because I had
moved the SSLProtocls  to theSSLHostConfig section moved the
useServerCipherSuitesOrder  attribute to the SSLHostConfig section and
renamed it to honorCipherOrder to fix that).
Also found I had to add the truststoreType and truststorePassword
attributes to the SSLHostConfig element (docs seem to say that's ONLY
for JSSE syntax - but I may be misunderstanding that),

long story short, I now have a Connector element that works correctly:
 







retested with tc-native 1.2.21 on the desktop...  and its working as
expected.
(Still not sure what was going on previously).

thanks, again.


On Tue, Feb 12, 2019 at 12:27 PM Mark Thomas  wrote:

> On 12/02/2019 17:21, John Palmer wrote:
> > using the old Connector/clientAuth="true" or the new
> > Connector/SSLHostConfig/  certificateVerification="REQUIRED"
> (tried
> > lowercase and without the D) format..doesn't seem to work properly.
> >
> > no matter what value I use or which format... the behavior seems to be
> that
> > the client cert is prompted for, but is optional (the web pages are
> > shown whether a cert is selected or Cancel is selected on the prompt.
> > (in the latter case, a JSP scriplet that shows X509 certificate content
> > throws an error, confirming that the client certifcate was not sent).
> >
> > (Openssl s_client cmd confirms that the "Acceptable client certificate CA
> > names"
> > from the trustStore specified ARE being sent).
> >
> > I don't doubt that I'm missing (mistyping or misunderstanding) something
> > (again), but I'm gonna ask for help a little sooner this time  rather
> than
> > continuing to beat a dead horse   :) ...
>
> Maybe. Or you might have hit a Tomcat bug.
>
> So, starting with a clean build of the latest 8.5.x source...
>
> Enable TLS (uncomment the second of the comment out TLS connectors in
> the default server.xml), switch it to NIO2 from APR/native and copy the
> key, cert, etc. into the correct locations.
>
> Starts with TLS enabled with NIO2 (JSSE) on 8443. Can connect with Chrome.
>
> Add certificateVerification="required" to the SSLHostConfig and restart.
>
> Starts with TLS enabled with NIO2 (JSSE) on 8443. Connection from Chrome
> rejected. Ah. No trust store configured on the connector.
>
> Add caCertificateFile="conf/ca-rsa-cert.pem" to SSLHostConfig and restart.
>
> Starts with TLS enabled with NIO2 (JSSE) on 8443. Connection from Chrome
> rejected. Realised I tried to use OpenSSL config and I'm using JSSE.
> Removed caCertificateFile="conf/ca-rsa-cert.pem" and added
> truststoreFile="conf/ca-rsa.jks" to SSLHostConfig.
>
> Starts with TLS enabled with NIO2 on 8443. Connection from Chrome
> prompts for client cert. Click cancel - connection rejected. As
> expected. Try again, this time selecting a certificate - connection
> allowed.
>
> All working as expected.
>
> Add Tomcat Native (so OpenSSL is usedd for TLS).
>
> Tomcat starts with NIO2 (OpenSSL) on port 8443.
>
> Prompted for user certificate. Click cancel. Connection refused.
>
> Try again. Prompted for certificate. Select valid cert. Connection
> refused. Ah. the trust store again. Switch back to the OpenSSL config.
>
> Tomcat starts with NIO2 (OpenSSL) on port 8443.
>
> Prompted for user certificate. Click cancel. Connection refused.
>
> Try again. Prompted for certificate. Select valid cert. Connection allowed.
>
> All seems to be working as expected here.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

tomcat 8.5.37, Http11Nio2Protocol (OpenSSL), clientAuth or certificateVerification options

[John Palmer]

using the old Connector/clientAuth="true" or the new
Connector/SSLHostConfig/  certificateVerification="REQUIRED" (tried
lowercase and without the D) format..doesn't seem to work properly.

no matter what value I use or which format... the behavior seems to be that
the client cert is prompted for, but is optional (the web pages are
shown whether a cert is selected or Cancel is selected on the prompt.
(in the latter case, a JSP scriplet that shows X509 certificate content
throws an error, confirming that the client certifcate was not sent).

(Openssl s_client cmd confirms that the "Acceptable client certificate CA
names"
from the trustStore specified ARE being sent).

I don't doubt that I'm missing (mistyping or misunderstanding) something
(again), but I'm gonna ask for help a little sooner this time  rather than
continuing to beat a dead horse   :) ...

thanks again..
John

Re: tomcat 8.5.37 specifying PKCS (.pfx) cert files in SSLHostConfig/Certificate elements

[John Palmer]

wow.  All working now. (I think- verifying the Client Cert prompt - borwser
is NOT prompting, but I may not have a cert for it to send)
certificateKeystoreFile etc instead of certificateKeyFile

and
truststoreFile instead of caCertificateFile

( I spent a lot of time searching and trying things. Glad I finally ASKED).

Thanks again.


On Mon, Feb 11, 2019 at 11:22 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> John,
>
> On 2/11/19 10:42, John Palmer wrote:
> > I'm new to implementing APR/tc-natiive for SSL/TLS on Windows
> > Server 2008R2, attepting to usse tomcat 8.5.37 specifying PKCS12
> > format in the SSLHostConfig/Certificate elements for the keystore
> > and truststore.. (I would prefer to drop the JKS format for several
> > reasons) questions are: is this allowed?
>
> Absolutely. And switching away from JCEKS/JKS files is a good idea.
> They never should have existed in the first place.
>
> > if so, what am I doing wrong?
>
> :)
>
> > ...while the old (tomcat 7) connector element format works very
> > well... for example:  > protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> > maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
> > keyAlias="FQDNservername" keystoreFile="C:\certs\servername.pfx"
> > keystorePass="password" keystoreType="PKCS12" clientAuth="true"
> > truststoreFile="C:\certs\truststore.pfx" truststoreType="PKCS12"
> > truststorePass="password"
> >>
> >  > /> 
> >
> > trying to use these .pfx files in the new
> > Connector/SSLHostConfig/Certificate elements doesn't work: (there's
> > no equivalent to the ...Type attribute for certificateFile,
> > caCertificateFile, and the description for each says ..."The format
> > is PEM-encoded." and no equivalent for the ...Password attribute
> > for caCertificateFile).
>
> You want to use certificateKeystoreType="PKCS12" and
> certificateKeystoreFile="C:/certs/truststore.pfx". Don't use
> backslashes. They will ruin your life. (But in this case, it should
> not matter which kind of slash you use.)
>
> I notice that you have another thread where you are trying to use
> tcnative. If you are using tcnative with the APR connector, you cannot
> use keystores such as the above. But you are specifically using the
> NIO2 protocol, so you will be using the OpenSSL JSSE provider, so I
> think you are okay.
>
> >  > protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> > maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
> >>
> >  > />  > caCertificateFile="C:\certs\trustStore.PFX"
> >>
>
> Change to truststoreFile="C:/certs/trustStore.PFX".
>
> >  > certificateKeyPassword="password" />
>
> Change to certificateKeystoreFile and make sure to set
> certificateKeystoreType="PKCS12". Also
> certificateKeystorePassword="password".
>
> >  
> >
>
> Hope that helps.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxhr2QACgkQHPApP6U8
> pFh8Xg/8D8bhkADQxGG/wr50VXMuZQDe8ubFQ0zAXWcloCKe2FwvH1p2PJ6ZeMAR
> +RR+a+laIraGSL6T81/4vGSPS87YYwGMnKumwyBCLBSNnj8U7y4mZaURvCgiAc1u
> LITmLrcAhBHrr20pj1ULFO9tKGKadXVGjhspJ3/CdH+pfxvDq+3MMdwW5D66YAiD
> qDV47Z0Avv3FB/PlXCprmfdTj98F4+O2giQn5WvuejmBotW+c3301qdolQIFYKAH
> hGi5Snr2ERLkm+FCbU/4GYhf7W+lD0OAKO7unBePRHvLphaCmbKCoecWTdiTSULb
> t7H+17DYy59nqxO2B+ExYBz5X2NCm/BjyUXsV5qQIQwQGjCdBbNTNBtaJFQ58SsV
> Yfmdp+dK5k9FfcEdR5aIyWmFHz7RosnBOOvn3pkIOqCMbzlACM7Qo0vYbX47OmH5
> F2Hxe3w4P2kBVXDr3gCUuUvb304hnDKcVcGxkIFlNaYcz9a0LwIF6KAKsbTOilhl
> cilCs9Fa/XYScvvwChw53ilVLDysl1RAifN2rNIRv+12vHqOyCEr/lpHow8xkrbN
> kG1JFKsQ9yBYqVydMTDgDevmqTvymPzAaWJhXSzTnIIkStacMTslxSaHCZP2R+Zk
> SoV9Wc/C8nZ5QnxEOn5Zn8HwM90+Y0Er6Ed/seKOn5SIVGTjzpo=
> =eR3x
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: how to use separate shared dlls for OpenSSL, APR, and libtcnative-1...

[John Palmer]

 > For Windows, you are better off using the all-in-one statically-linked
> DLL provided by the Tomcat team.
...
> In general, the Tomcat team tries to keep on top of the latest news
> and releases from both APR and OpenSSL, so you shouldn't have to wait
> too long between a newly-published version of APR or OpenSSL and a new
> release of tcnative.

I'm fine with that... this week we've seen the new TC-Native released and
then tomcat 9 updated Friday and 8.5 updated over the weekend (I think).
Pretty darn quick, in any case.

> I would question whether or not you really need libtcnative at all.

me too. but see below:

> Are you going to be using a Tomcat installation without any kind of
> load-balancer or reverse-proxy in between it and your users?

We're using a load-balancer, but terminating the SSL (TLS) connection at
Tomcat rather than at the load-balancer...
(we need the client certificate info for authentication. I understand that
with a SSL connection terminated at a load balance, the client certificate
info can be forwarded to tomcat - but I don't want to fight that battle
just now).
I'm investigating using tc-native for:
improved SSL (TLS) processing compared to the JSSE implementation (I hope)
TLS1.3 support
HTTP/2 Support
(possibly the use of more mainstream certs/truststore format (Windows
environment) than the JKS format  -
(not that using JKS  format is a big deal, but I have found Key Store
Explorer to be REAL helpful in figuring out problems with keystores or
truststores that weren't real obvious using keytool.exe by itself
and in adding/removing Issuer or Root certs as new ones come into use or
expire).

Thanks.,..

On Mon, Feb 11, 2019 at 11:38 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> John,
>
> On 2/11/19 10:46, John Palmer wrote:
> > (I'm new to using TC-native, interested in how to accomplish "In
> > security conscious production environments, it is recommended to
> > use separate shared dlls for OpenSSL, APR, and libtcnative-1, and
> > update them as needed according to security bulletins. "
>
> For Windows, you are better off using the all-in-one statically-linked
> DLL provided by the Tomcat team. If you really want separate ones,
> you'll need to build everything yourself.
>
> I think that quote is easy to misinterpret. The problem is not the
> fact that the library is statically-linked and therefore less secure.
> The problem is that the native library bundles 3 separate packages:
> Apache Portable Runtime (APR), OpenSSL, and Tomcat's native library
> (libtcnative). Because they are bundled together, you cannot upgrade
> any single one of them independently of the others.
>
> If APR publishes a fix for a vulnerability, you cannot upgrade just
> apr-x.y.z.dll to get that fix. Instead, you'd have to wait for the
> Tomcat team to publish an updated bundle that includes that new
> version. Save with OpenSSL, etc.
>
> In general, the Tomcat team tries to keep on top of the latest news
> and releases from both APR and OpenSSL, so you shouldn't have to wait
> too long between a newly-published version of APR or OpenSSL and a new
> release of tcnative.
>
> If you have the capability of building your own libraries, then you
> can always get the latest from the upstream source and stay even more
> up-to-date than you would is you wanted for the releases from Tomcat.
>
> > Apparently I need a concrete example (step-by-step, where to get
> > the dlls, where to put them (and make sure tomcat finds them)
> > etc...   preferably I wouldn't have to compile anything myself.
>
> If you don't want to compile yourself, you'll need to trust ...
> someone else. The Tomcat team only publishes the all-in-one DLL.
>
> I would question whether or not you really need libtcnative at all.
> Are you going to be using a Tomcat installation without any kind of
> load-balancer or reverse-proxy in between it and your users?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxhsygACgkQHPApP6U8
> pFj7Rg//f75XYfYrgJSe14KeizoybHnzpDbZ/XDxyZ8ytTBU5hx2YIQBR9ucrYYA
> x01ArX6dCU209EBkLnXCThNXqrxv/pOvRo4MUiUw+oUMg5sjNL61cz/DaqwCj4WX
> PtzqaYSlUhYmAiRPrdv5zwvmqMR6L8ArHfpTqCw6Tov2fdlyyc9B0Yb+Om98Jn3a
> wLj+o24FOMm9Vpuz2EyMuHhslz1xiGK7O7CyiGXGK9ZjigcqFQiR77PtnZYXnlhk
> jM0DJKFFo+tMri5zNs7bkAT/2DOhKmlMfD+G3LcTL4PZKbx6r30BqgXNf/b++A+8
> gmOtgLHZmCK9/UcI3TX3pk2IciDZbHaCDa7YOLiFAkzSjSd3QpdxnIDJ/aoiqcz2
> mkTyXEHeErNClzX+P+gkK2oVyz5B28EeQlC0ls2Q0SecI3DeXx+ZgO9MIsofMzyG
> lkG1XL9oNYA/6wOaKXMYB/xA0dbiYtpQZsVCR65I0FjJ3cD7pvvez8UjAzrvYObm
> LXi0fVCRrlHSDVfRCt5OZ/P3c8l2/1cz3k0jTbA9k+NEq5+tvmErMuEWnXadd5Y2
> aukaVKg3afR6SvGTBpaDS38peyFOFjkR5uJ0+9H4ZKogCqiUqesqVSzh2hhKqIIx
> 4wqP1VwtsL/rujLm0p3nr9c3HbamzznpCXXQOy9oOAMbZwmeTag=
> =9OOQ
> -END PGP SIGNATURE-
>

how to use separate shared dlls for OpenSSL, APR, and libtcnative-1...

[John Palmer]

(I'm new to using TC-native, interested in how to accomplish "In security
conscious production environments, it is recommended to use separate shared
dlls for OpenSSL, APR, and libtcnative-1, and update them as needed
according to security bulletins. "

Apparently I need a concrete example (step-by-step, where to get the dlls,
where to put them (and make sure tomcat finds them) etc...   preferably I
wouldn't have to compile anything myself.

thanks...

tomcat 8.5.37 specifying PKCS (.pfx) cert files in SSLHostConfig/Certificate elements

[John Palmer]

I'm new to implementing APR/tc-natiive for SSL/TLS on Windows Server
2008R2, attepting to usse tomcat 8.5.37 specifying PKCS12 format in the
SSLHostConfig/Certificate elements for the keystore and truststore..
(I would prefer to drop the JKS format for several reasons)
questions are:
is this allowed?
   if so, what am I doing wrong?

...while the old (tomcat 7) connector element format works very well... for
example:




trying to use these .pfx files in the new
Connector/SSLHostConfig/Certificate elements doesn't work:
 (there's no equivalent to the ...Type attribute for certificateFile,
caCertificateFile,
  and the description for each says ..."The format is PEM-encoded."
  and no equivalent for the ...Password attribute for caCertificateFile).








.. the above gives errors:
11-Feb-2019 08:25:06.415 SEVERE [main]
org.apache.catalina.core.StandardService.initInternal Failed to initialize
connector [Connector[org.apache.coyote.http11.Http11Nio2Protocol-443]]
 org.apache.catalina.LifecycleException: Failed to initialize component
[Connector[org.apache.coyote.http11.Http11Nio2Protocol-443]]
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
at
org.apache.catalina.core.StandardService.initInternal(StandardService.java:552)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.startup.Catalina.load(Catalina.java:638)
at org.apache.catalina.startup.Catalina.load(Catalina.java:661)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:309)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
Caused by: org.apache.catalina.LifecycleException: Protocol handler
initialization failed
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:995)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
... 12 more
Caused by: java.lang.IllegalArgumentException: SSLHostConfig attribute
certificateFile must be defined when using an SSL connector
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:115)
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:86)
at org.apache.tomcat.util.net.Nio2Endpoint.bind(Nio2Endpoint.java:161)
at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1087)
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:265)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:581)
at
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:68)
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:993)
... 13 more
Caused by: java.io.IOException: SSLHostConfig attribute certificateFile
must be defined when using an SSL connector
at
org.apache.tomcat.util.net.jsse.JSSEUtil.getKeyManagers(JSSEUtil.java:222)
at
org.apache.tomcat.util.net.openssl.OpenSSLUtil.getKeyManagers(OpenSSLUtil.java:94)
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:113)
... 20 more

Adding certificateFile="C:\certs\servername.pfx" to the Certificate element
causes this error (apparently its expecting a PEM file):
11-Feb-2019 08:40:56.179 INFO [main]
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
["https-openssl-nio2-443"]
11-Feb-2019 08:40:56.226 WARNING [main]
org.apache.tomcat.util.net.openssl.OpenSSLContext.init Error initializing
SSL context
 java.lang.Exception: Unable to load certificate key
C:\certs\satlwsrmdwb01.pfx (error:0909006C:PEM routines:get_name:no start
line)
at org.apache.tomcat.jni.SSLContext.setCertificate(Native Method)
at
org.apache.tomcat.util.net.openssl.OpenSSLContext.init(OpenSSLContext.java:284)
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:113)
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:86)
at org.apache.tomcat.util.net.Nio2Endpoint.bind(Nio2Endpoint.java:161)
at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1087)
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:265)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:581)
at
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:68)
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:993)
at 

tomcat 8.5.35 warning using NIO 2 (or NIO) connector w APR: An unknown setting with identifier [2147483647] and value [2] was ignored

[John Palmer]

I'm working with tomcat 8.5.35 to configure SSL
(current system is tomcat 7.5 using JKS keystore and truststore)..

I finally have the certificate parts working with the default (commented
out) APR connector..
it bothers me (doesn't seem intuitive) that the logging shows
"useAprConnector [false]" as in:
INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true]

so I'm experimenting with changing the protocol section from:

Re: tomcat Finding!

[John Palmer]

I found this to be easier to accomplish (and maintain):

add to the Host section of server.xml:


(this will disable the tomcat version number and the stacktrace  - the
defaults for these are "true")


On Fri, Dec 14, 2018 at 10:18 AM  wrote:

> Good Morning,
> I'm encountering following scan finding errors and couldn't find way to
> mitigate this.
>
> Tomcat 8.5.32
> 12085
> Apache Tomcat Default Files
> The following default files were found
> :/nessus-check/default-404-error-page.html
> Delete the default index page and remove the example JSP and servlets.
> Follow the Tomcat or OWASP instructions to replace or modify the default
> error page.
>
> Thank you,
> Danyaal
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Please help me in enabling SSL certificate

[John Palmer]

your server.xml shows TWO connectors for port 8443; that second one (with
all the  certificate entries) is then causing the errror:

> Caused by: java.net.BindException: Address already in use

As that one is probably the one you want to be using, delete or comment out
the first connector for port 8443


On Thu, Aug 2, 2018 at 1:24 PM, Venkataraman Srinivasan <
venkataraman.sriniva...@gcrta.org> wrote:

>
> Hi ,
>
> I am using tomcat version 8.5.32
>
>
> I made the below entry  in Server.xml
>
>  
>
> 
> 
>
>
> 
> connectionTimeout="2"
> />
>
>
>
>
> sslImplementationName="org.apache.tomcat.util.net.jsse.
> JSSEImplementation"
> maxThreads="200" secure="true"  scheme="https" >
> keystorePass="x" type="RSA"
> clientAuth="false" SSLEnabled="true"
> sslProtocol="TLS"
>  >
>
> 
>
> '
> When I tried to login, https://webapxt03.rta:8443, the log file
> catalina.2018-08-02.log recorded as below
>
>
> CATALINA.OUT has got entries as below
>
>
> 02-Aug-2018 14:04:24.926 SEVERE [main] 
> org.apache.catalina.core.StandardService.initInternal
> Failed to initialize connector [Connector[HTTP/1.1-8443]]
>  org.apache.catalina.LifecycleException: Failed to initialize component
> [Connector[HTTP/1.1-8443]]
> at org.apache.catalina.util.LifecycleBase.init(
> LifecycleBase.java:112)
> at org.apache.catalina.core.StandardService.initInternal(
> StandardService.java:549)
> at org.apache.catalina.util.LifecycleBase.init(
> LifecycleBase.java:107)
> at org.apache.catalina.core.StandardServer.initInternal(
> StandardServer.java:875)
> at org.apache.catalina.util.LifecycleBase.init(
> LifecycleBase.java:107)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:632)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:655)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:309)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
> Caused by: org.apache.catalina.LifecycleException: Protocol handler
> initialization failed
> at org.apache.catalina.connector.Connector.initInternal(
> Connector.java:995)
> at org.apache.catalina.util.LifecycleBase.init(
> LifecycleBase.java:107)
> ... 12 more
> Caused by: java.net.BindException: Address already in use
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Net.java:444)
> at sun.nio.ch.Net.bind(Net.java:436)
> at sun.nio.ch.ServerSocketChannelImpl.bind(
> ServerSocketChannelImpl.java:214)
> at sun.nio.ch.ServerSocketAdaptor.bind(
> ServerSocketAdaptor.java:74)
> at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.
> java:210)
> at org.apache.tomcat.util.net.AbstractEndpoint.init(
> AbstractEndpoint.java:1086)
> at org.apache.tomcat.util.net.AbstractJsseEndpoint.init(
> AbstractJsseEndpoint.java:268)
> at org.apache.coyote.AbstractProtocol.init(
> AbstractProtocol.java:581)
> at org.apache.coyote.http11.AbstractHttp11Protocol.init(
> AbstractHttp11Protocol.java:68)
> at org.apache.catalina.connector.Connector.initInternal(
> Connector.java:993)
> ... 13 more
>
>
> I used SSL/TLS Configuration HOW-TO of Apache Tomcat 7 document
>
>
>
> >>> Christopher Schultz  8/2/2018 12:44 PM
> >>>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Venkataraman,
>
> On 8/2/18 12:14 PM, Venkataraman Srinivasan wrote:
> > Chris,
> >
> > Thanks for your reply.  I will implement your recommendations in my
> > next iterations.
> >
> > Currently I did as below.
> >
> > I copied the keystore file as /home/apexadmin/.keystore
> >
> > and made below entry in server.xml
>
> What version of Tomcat are you using? Which part of the user guide are
> you reading? I just want to make sure you are following the right
> guide for the right version.
>
> >  > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > maxThreads="200" redirectPort="8443" scheme="https" >  > certificateFile="/home/apexadmin/.keystore" keystorePass="x"
> > type="RSA" clientAuth="false" SSLEnabled="true" sslProtocol="TLS"
> >>
> >  
>
> You will need to set a few more attributes on the :
>
>SSLEnabled="true"
>secure="true"
>
> The next part depends upon your Tomcat version.
>
> > Opened the port 8443 and recycled tomcat.
>
> The  defined above is listening on port 8080. That is
> unusual; most people would expect port 8080 to be a plaintext HTTP
> 

ErrorReportValve styling (CSS) not included when both showReport and showServerInfo set to false

[John Palmer]

while it's documented that the styling will be lost when both settings for
ServerReport/ServerInfo are set to false... eg by adding this to server.xml:



(and I confirmed this recently)

from looking at the source for ErrorReportValve   for tomcat 7.0.78 it
LOOKS like this would be easy to fix:
(however, I'm neither a tomcat/java/HTML or CSS expert, so there may be
very good reasons this is done this way):

currently:

StringBuilder sb = new StringBuilder();

sb.append("");
if(showServerInfo || showReport){
sb.append("");
if(showServerInfo) {
sb.append(ServerInfo.getServerInfo()).append(" - ");
}
sb.append(smClient.getString("errorReportValve.errorReport"));
sb.append("");
sb.append("<!--");
sb.append(org.apache.catalina.util.TomcatCSS.TOMCAT_CSS);
sb.append("--> ");
} else {
sb.append("");
sb.append(smClient.getString("errorReportValve.errorReport"));
sb.append("");
}
sb.append("");

 it looks to me like simply moving the three lines for style/css/style
outside the If statement would fix this, like so:

StringBuilder sb = new StringBuilder();

sb.append("");
if(showServerInfo || showReport){
sb.append("");
if(showServerInfo) {
sb.append(ServerInfo.getServerInfo()).append(" - ");
}
sb.append(smClient.getString("errorReportValve.errorReport"));
sb.append("");
} else {
sb.append("");
sb.append(smClient.getString("errorReportValve.errorReport"));
sb.append("");
}
// move style lines outside of if(showServerInfo || showReport){
section... above
    sb.append("<!--");
sb.append(org.apache.catalina.util.TomcatCSS.TOMCAT_CSS);
sb.append("--> ");
sb.append("");
...

or am I missing (or just ignorant of ) something?

John Palmer

Re: server.xml password encryption instead of plain text

[John Palmer]

I haven't tested it yet, but if you're on a Windows platform you MAY be
able to tell Tomcat to use the Windows Certificate Store (an thus NOT have
a password in server.xml) by adding something like this to the Java Options:
-Djavax.net.ssl.trustStoreProvider=SunMSCAPI
-Djavax.net.ssl.trustStoreType=Windows-ROOT
-Djavax.net.ssl.trustStore=NONE
-Djavax.net.ssl.keyStoreProvider=SunMSCAPI
-Djavax.net.ssl.keyStoreType=Windows-MY
-Djavax.net.ssl.keyStore=NONE

.. and this may not work at all..


On Thu, May 25, 2017 at 7:46 AM, Vidyadhar  wrote:

> On Thu, 25 May 2017 at 6:01 PM, Dhaval Jaiswal 
> wrote:
>
> > How can we avoid defining plain text password in server.xml​ or is there
> a
> > way i can encrypt the password in server.xml. ​
> >
> There are couple of examples on https://wiki.apache.org/
> tomcat/FAQ/Password
> --
> Regards,
> Vidyadhar
>

request.getAttribute(javax.servlet.request.X509Certificate) returns NULL with APR connector on Tomcat 7.0.47 when using FireFox 26

[John Palmer]

Our installations have been working fine for several years, but we're
having to replace the existing 32-bit Windows servers with 64-bit Windows
servers,
and I'm trying to take advantage of this effort to simply the
configuration...
we inherited this with IIS in front of Tomcat, using the Jakarta ISAPI
Filter , with no good reason given for doing it this way. (the majority of
our content is served from a java app, no need to have a more robust web
server in front of this for static content that I can see)
by removing IIS so Tomcat stands alone.


Getting the default (none APR) connector working has been pretty
easy...we've had some other projects needing similar (.jks cert file)
setups for the server certs, CA certs etc...

However, I've been concerned that client cert revocation checks would
contribute to network congestion as it appears that ONLY CRLs are available
to use with this connector

Apparently the APR connector also supports OCSP  checks
I've tried configuring this as an APR connector..  after some time with
this I seem to have the certs in the correct format for both the server
cert and the client cert CA's - connections occur, no errors.

HOWEVER - I have code  in several JSP files (eg, server-side) using
request.getAttribute(javax.servlet.request.X509Certificate)

this is working fine using IE 8 and IE 9, but not with FireFox 26.0 - where
it returns NULL.

Using Wireshark, I don't see any noticable difference in the server's
response to the browser... and the browser responds in each case, with the
client cert I select as well as it's issuer. (I currently have only the two
Root certs in the SSLCACertificateFile and this seems to be working fine).

After fighting this for a while, I retreated...

set up IIS 7.5 and the 64-bit Jakarta ISAPI Filter and have this working,
but again, I'd prefer to dump IIS, so I've returned to this;

Still works fine with IE 9 (and presumably  IE 8).

SOMETIMES, selecting one of my two available certs results in
request.getAttribute returning the cert information... (FireFox 26, WIndows
7, ActivCard client), but usually not.

Wireshark on both server and workstation hasn't helped me...

 I thought perhaps certificate revocation checking was failing - in fact,
the only place I see this happening is on FireFox, where apparently it
issues an OCSP request back to the tomcat server (I would have thought it
would go directly to the URL listed in the cert for OCSP or CRL checks) and
receives a GOOD response. I don't seem to see ANY OCSP requests issued by
the server... or any CRL requests...
I don't know if any additional configuration is needed to enable OCSP
checking in Tomcat with the APR connector..

I've enabled logging with tomcat's logging.properties without seeing
anything interesting... don't see how to log what the APR stuff is doing,
but looking at the source, it appears there isn't much logging code in
there...

from the server.xml file (each entry on it's own line here to make it more
readable):

!-- APR SSL Coyote HTTP/1.1 Connector --

Connector
protocol=org.apache.coyote.http11.Http11AprProtocol
port=443
scheme=https
secure=true
URIEncoding=UTF-8
connectionTimeout=2
maxThreads=200
minSpareThreads=25
SSLEnabled=true
SSLCertificateFile=./conf/crt.pem
SSLCertificateKeyFile=./conf/key.pem
SSLPassword=xxx
SSLCACertificateFile=./conf/ca-roots.pem
SSLProtocol=TLSv1
SSLVerifyClient=require
SSLVerifyDepth=10
/

Any ideas?

request.getAttribute(javax.servlet.request.X509Certificate) returns NULL for AJP connector

[John Palmer]

 We have two similar production environments which use:
request.getAttribute(javax.servlet.request.X509Certificate)
for several purposes.

These use tomcat behind IIS using the Jakarta connector (aka reverse proxy)
and have been running since 2006 and 2011 respectively without significant
issues ... other than perhaps insufficient memory (and sometimes IIS can't
talk to Tomcat and everything has to be restarted, multiple times, to
resolve).

We're trying to upgrade/replace these servers with 64-bit Windows OS  due
to memory constraints caused by the use of  32-bit OS, and these attributes
(and related SSL attributes in Tomcat) are now returning NULL in our DEV
environment

Old environment:
IIS 5.0 on WIndows Server 2003 SP2, Jakarta Isapi Redirector 1.2.37, TomCat
7.0.47

(While researching how to set up Jakarta Isapi Redirector in IIS 7.5 with
a 64-bit Windows 2008 I saw multiple people reporting issues with poor
performance, lockups etc, and decided we would try Bon Code instead.)

New Environment
IIS 7.5 on Win Server 2008 R2, Bon Code 1.0.17, TomCat 7.0.47


IIS is configured with Client Cert Required; browser is being prompted for
cert, and cert info is being sent to IIS.

According to Bon Code logs, request headers are being populated with plenty
of information, including client cert and client issuer cert information.

It looks like Tomcat is receiving these request headers, but is not
populating the request attributes related to SSL and Cert information, but
I can't see why in the logs, even after turning the logs to ALL and wading
through the copious output.

After looking through the Tomcat source multiple times, I don't see how the
AJP connector can populate these request attributes at all - but it is in
our current (32-bit OS) environment.
-
I understand that Tomcat is NOT doing the SSL connection itself - IIS is,
just as Apache Web Server can be made to do, but my understanding is that
Tomcat should be able to populate these attributes from information sent
with the request throught the AJP connector (eg, in the Request Headers),
That seems to be working wonderfully in our current environment...

I suspect that I simply have something not configured properly - but is it
IIS 7.5, Bon Code, or Tomcat?

After multiple attempts to resolve this I'm at a loss..
your help appreciated...
-

Tomcat Server.xml (AJP connector):
Connector URIEncoding=*UTF-8* enableLookups= *false* port=*8029*
protocol=*AJP/1.3* redirectPort=*8443* /
(added  tomcatAuthentication= *false*, scheme=https secure=true
 without making any difference)

Bon Code config:
Settings
Serverlocalhost/Server
Port8029/Port
EnableRemoteAdminFalse/EnableRemoteAdmin
EnableHeaderDataSupportTrue/EnableHeaderDataSupport
ForceSecureSessionFalse/ForceSecureSession
AllowEmptyHeadersFalse/AllowEmptyHeaders
LogLevel4/LogLevel
LogDirc:\temp/LogDir
/Settings

(Added ForceSecureSessionTrue/ForceSecureSession
 -- this caused SSL session ID:
*getAttribute(javax.servlet.request.ssl_session)
 *to populate. No other difference).

---
code in jsp file to show these attributes:


/** prints the request headers being passed in */
out.println (brbrRequest Headers:  br);
   EnumerationString headerNames = request.getHeaderNames();
while (headerNames.hasMoreElements()) {
String headerName = headerNames.nextElement();
String headerValue = request.getHeader(headerName);
out.println(headerName +  =  + headerValue + br);
}

/** returns plenty of stuff for Bon Code, very little for Jakarta */

*/** *not** reported by request.getAttributeNames() ! */

out.println(brbrSSL Attributes:  br);

out.println(javax.servlet.request.cipher_suite:  +
request.getAttribute(javax.servlet.request.cipher_suite) + BR);
out.println(javax.servlet.request.key_size:  +
request.getAttribute(javax.servlet.request.key_size) + BR);
out.println(javax.servlet.request.X509Certificate:  +
request.getAttribute(javax.servlet.request.X509Certificate) + BR);
out.println(javax.servlet.request.ssl_session:  +
request.getAttribute(javax.servlet.request.ssl_session) + BR);
out.println(SSL_PROTOCOL:  + request.getAttribute(SSL_PROTOCOL) +
BR)
---
result:

SSL Attributes:
javax.servlet.request.cipher_suite: null
javax.servlet.request.key_size: 2048
javax.servlet.request.X509Certificate: null
javax.servlet.request.ssl_session: on
SSL_PROTOCOL: null


---

Re: request.getAttribute(javax.servlet.request.X509Certificate) returns NULL for AJP connector (possible Bon Code issue?)

[John Palmer]

Konstantin:
Thanks for the suggestion - I'll hang on to that link.
I was ready to try running Tomcat with a debugger... the instructions I
found were for using Eclipse (which I already had set up, but not with the
TomCat source)... but I was reluctant to deal with another steep learning
curve.

Logging EVERYTHING didn't show me anything useful - except perhaps to tell
me ( by its absence) that the problem is not in Tomcat.

However, (see the other response I'll have here shortly) - I think that
Christopher Schultz has hit the nail on the head.. as you''ll see in my
response to him


On Tue, Jan 28, 2014 at 12:11 PM, Konstantin Kolinko knst.koli...@gmail.com
 wrote:

 2014-01-28 John Palmer johnpalm...@gmail.com:
   We have two similar production environments which use:
  request.getAttribute(javax.servlet.request.X509Certificate)
  for several purposes.
 
  These use tomcat behind IIS using the Jakarta connector (aka reverse
 proxy)
  and have been running since 2006 and 2011 respectively without
 significant
  issues ... other than perhaps insufficient memory (and sometimes IIS
 can't
  talk to Tomcat and everything has to be restarted, multiple times, to
  resolve).
 
  We're trying to upgrade/replace these servers with 64-bit Windows OS  due
  to memory constraints caused by the use of  32-bit OS, and these
 attributes
  (and related SSL attributes in Tomcat) are now returning NULL in our DEV
  environment
 
  Old environment:
  IIS 5.0 on WIndows Server 2003 SP2, Jakarta Isapi Redirector 1.2.37,
 TomCat
  7.0.47
 
  (While researching how to set up Jakarta Isapi Redirector in IIS 7.5
 with
  a 64-bit Windows 2008 I saw multiple people reporting issues with poor
  performance, lockups etc, and decided we would try Bon Code instead.)
 
  New Environment
  IIS 7.5 on Win Server 2008 R2, Bon Code 1.0.17, TomCat 7.0.47
 
 
  IIS is configured with Client Cert Required; browser is being prompted
 for
  cert, and cert info is being sent to IIS.
 
  According to Bon Code logs, request headers are being populated with
 plenty
  of information, including client cert and client issuer cert information.
 
  It looks like Tomcat is receiving these request headers, but is not
  populating the request attributes related to SSL and Cert information,
 but
  I can't see why in the logs, even after turning the logs to ALL and
 wading
  through the copious output.
 
  After looking through the Tomcat source multiple times, I don't see how
 the
  AJP connector can populate these request attributes at all - but it is in
  our current (32-bit OS) environment.
  -
  I understand that Tomcat is NOT doing the SSL connection itself - IIS is,
  just as Apache Web Server can be made to do, but my understanding is that
  Tomcat should be able to populate these attributes from information sent
  with the request throught the AJP connector (eg, in the Request Headers),
  That seems to be working wonderfully in our current environment...
 
  I suspect that I simply have something not configured properly - but is
 it
  IIS 7.5, Bon Code, or Tomcat?
 
  After multiple attempts to resolve this I'm at a loss..
  your help appreciated...
  -
 
  Tomcat Server.xml (AJP connector):
  Connector URIEncoding=*UTF-8* enableLookups= *false* port=*8029*
  protocol=*AJP/1.3* redirectPort=*8443* /
  (added  tomcatAuthentication= *false*, scheme=https secure=true
   without making any difference)

 I do not have a real answer, but if you have come this far, maybe you
 want to try
 running Tomcat under debugger? See

 http://wiki.apache.org/tomcat/FAQ/Developing#Debugging

 The above configuration of a Connector selects either a BIO or an
 APR connector (depending on presence of tcnative-1.dll). Which
 connector implementation is actually used should be visible from
 startup logs.

 A place of interest for a breakpoint is
 org.apache.coyote.ajp.AbstractAjpProcessor#prepareRequest().
 Look for 'case Constants.SC_A_SSL_CERT' there.

 Another place is AbstractAjpProcessor#action(...), see
 ActionCode.REQ_SSL_ATTRIBUTE there.

 Best regards,
 Konstantin Kolinko

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: request.getAttribute(javax.servlet.request.X509Certificate) returns NULL for AJP connector (possible Bon Code issue?)

[John Palmer]

Chris:
Thanks for the response.
I think we can end this discussion - you have pretty much nailed it, I
think.

The great thing about having to pull together all the information I've
gathered over that last month to make this post, is that it lets me see
what I've been too close to see, in this case, that the differences are IIS
5 vs 7.5 and Jakarta vs Bon Code.

I took another look at the request headers returned by Jakarta (no certs,
no SSL info, only about 5 request headers) as opposed to that returned by
Bon Code (about 2 dozen request headers, most ignored by Tomcat), to
realize that the request headers probably weren't the information source
from Jakarta.

Re-reading the Tomcat Connector docs and pages for the 1,000th or so time,
the phrase
SSL attributes of the client connection are passed via the AJP protocol
jumped out at me, finally, as meaning that this wasn't sent by request
headers, but as ATTRIBUTES.

Sure enough, reading through the source (NOT my strong point) of the
Jakarta Isapi Redirector 1.2.37 reveals that it IS putting the SSL info
into the request forwarded to the AJP connector (TomCat) as Attributes,
and by contrast, the Bon Code source is NOT.

I'll recommend/ask  that Bilal look into this (I'm not prepared to attempt
this myself, yet)... I may be all wrong still...
and try to use the Jakarta for now, instead.

 If it turns out that Bon Code is the problem, I believe that Bilal
 lurks on the list. I've added Bon Code to the subject to get his
 attention.

Thanks - I meant to do that, and forgot...


 Why not try configuring mod_jk ISAPI redirector in your new
 environment to see if Bon Code is the problem?

I will...

Thanks for the encouragement, and making me feel that I'm not alone in this.


On Tue, Jan 28, 2014 at 12:02 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 John,

 On 1/28/14, 12:41 PM, John Palmer wrote:
  We have two similar production environments which use:
  request.getAttribute(javax.servlet.request.X509Certificate) for
  several purposes.
 
  These use tomcat behind IIS using the Jakarta connector (aka
  reverse proxy) and have been running since 2006 and 2011
  respectively without significant issues ... other than perhaps
  insufficient memory (and sometimes IIS can't talk to Tomcat and
  everything has to be restarted, multiple times, to resolve).
 
  We're trying to upgrade/replace these servers with 64-bit Windows
  OS  due to memory constraints caused by the use of  32-bit OS, and
  these attributes (and related SSL attributes in Tomcat) are now
  returning NULL in our DEV environment
 
  Old environment: IIS 5.0 on WIndows Server 2003 SP2, Jakarta Isapi
  Redirector 1.2.37, TomCat 7.0.47
 
  (While researching how to set up Jakarta Isapi Redirector in IIS
  7.5 with a 64-bit Windows 2008 I saw multiple people reporting
  issues with poor performance, lockups etc, and decided we would try
  Bon Code instead.)
 
  New Environment IIS 7.5 on Win Server 2008 R2, Bon Code 1.0.17,
  TomCat 7.0.47
 
 
  IIS is configured with Client Cert Required; browser is being
  prompted for cert, and cert info is being sent to IIS.

 So, the old production setup uses mod_jk ISAPI redirector and it
 works. The new production setup uses Bon Code and doesn't work. I
 may have a suggestion as to the difference between setups, and a
 possible reason why this isn't working.

  According to Bon Code logs, request headers are being populated
  with plenty of information, including client cert and client issuer
  cert information.
 
  It looks like Tomcat is receiving these request headers, but is
  not populating the request attributes related to SSL and Cert
  information, but I can't see why in the logs, even after turning
  the logs to ALL and wading through the copious output.
 
  After looking through the Tomcat source multiple times, I don't see
  how the AJP connector can populate these request attributes at all
  - but it is in our current (32-bit OS) environment.

 It looks like it happens in AbstractAjpProcessor.action().

  - I understand that Tomcat is NOT doing
  the SSL connection itself - IIS is, just as Apache Web Server can
  be made to do, but my understanding is that Tomcat should be able
  to populate these attributes from information sent with the request
  throught the AJP connector (eg, in the Request Headers), That seems
  to be working wonderfully in our current environment.

 mod_jk does not use HTTP headers to send SSL information. Those data
 are sent using a different mechanism. Bon Code should be using the
 same mechanism.

  I suspect that I simply have something not configured properly -
  but is it IIS 7.5, Bon Code, or Tomcat?

 Why not try configuring mod_jk ISAPI redirector in your new
 environment to see if Bon Code is the problem?

 
  After multiple attempts to resolve this I'm at a loss.. your help
  appreciated