Re: SSL Certificate Renewal

[Ognjen Blagojevic]

Nitin

On 13.6.2019. 07.37, Nitin Kadam wrote:

I have apache tomcat server running with publicly signed SSL certificate
configured in server.xml, the same certificate is expiring in next week, I
need steps to the to renew of same.
*Server OS: Windows 2012 R2*
*Apache Tomcat/8.5.38*

1. How to generate new CSR with new key alias
2. How to import the new. cert & intermediate certificate chain in .jks
format
3. what about keystore & current key alias


kindly guide me, as I will be performing same first time.


You can find the instructions here:

http://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html#Installing_a_Certificate_from_a_Certificate_Authority

Regards,
Ognjen

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

Re: Fwd: Tomcat question

[Ognjen Blagojevic]

Zahi,

On 30.4.2018. 11:09, Zahi Fail wrote:

curl -X POST \
   http://localhost:8080/userManagement/rest/Traffic/users2 \
   -H 'Authorization: Basic dG9tY2F0OnMzY3JldA==' \
   -H 'Cache-Control: no-cache' \
   -H 'Content-Type: application/json' \
   -H 'Postman-Token: 71819f33-6206-02c5-5cf2-8de6347fc154' \
   -d '[{"id":1, "code":2, "time":"2009-02-15", "cycleSecond":22,
"programNumber":1221, "stageNumber":22, "moves":"22",
"detectors":"fead","conditions":"2ddsa"}]'


First, please don't top post. Read mailing list guidelines here:

  http://tomcat.apache.org/lists.html#tomcat-users

Regarding the problem, base64 string "dG9tY2F0OnMzY3JldA==" decodes to 
"tomcat:s3cret", which is, according to your previously posted 
tomcat-users.xml file, user in the role "manager-gui".


On the other hand, your web.xml auth-constraint configuration expects 
the user in the role "manager".


-Ognjen

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

Re: Fwd: Tomcat question

[Ognjen Blagojevic]

Zahi,

On 25.4.2018. 13:19, zahi.f...@gmail.com wrote:

I configured in my conf\server.xml file the realm as below:


Ok, so the configuration looks fine.

You said you are using Postman to send the request. Can you paste the 
`curl` command that the postman can generate for you just to check if it 
looks Ok?


For instance, this would be the right curl command:

  curl -u admin:falcon -X POST http://your.server/webapp/

While those are not:

  curl -u admin:falco -X POST http://your.server/webapp/ (typo in 
password, HTTP 401)


  curl -X POST http://your.server/webapp/ (no credentials specified, 
HTTP 401)


  curl -u tomcat:s3cret -X POST http://your.server/webapp/ (wrong role, 
HTTP 403)


  curl -u admin:falcon -X GET http://your.server/webapp/ (GET instead 
of POST, HTTP status code... it depends)


-Ognjen



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

Re: Tomcat question

[Ognjen Blagojevic]

Zahi,

On 23.4.2018. 16:38, Zahi Fail wrote:
> This is the following code from my web.xml file:
...
> *and in the tomcat-user.xml i have updated the code as below: *
...

You need to configure appropriate realm. Did you do that? You can do it 
in your webapp's context.xml, or in server.xml file, but the former 
method is recommended, because of easier deployment.


Take a look at:

  https://tomcat.apache.org/tomcat-9.0-doc/realm-howto.html

If you want to keep usernames and passwords in XML file (like 
tomcat-users.xml), you should use UserDatabaseRealm, but you also have 
other options for storing credentials -- e.g. SQL database or LDAP 
directory.


-Ognjen

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

Re: Facing issue while configuring SSL

[Ognjen Blagojevic]

Román,

On 15.7.2016 5:01, Román Valoria wrote:

The SSL Certificate was created using the wrong FQDN, which meant that the
hostname to IP address resolution done by the browser was failing. The
telnet command was done using the wrong FQDN, while openssl using
localhost. On top of that, since the FQDN to IP was not working, Devendra
had created a host alias in the local host file, which further complicated
troubleshooting.


Great. Thanks for detailed feedback.

-Ognjen

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

Re: Facing issue while configuring SSL

[Ognjen Blagojevic]

Devendra,

On 14.7.2016 10:38, Devendra Sengar wrote:

But the tomcat server is started without any error but won't able to open
the home page of tomcat giving the error like:
This site can’t be reached
The webpage at *https://:8443/* might be temporarily down or it
may have moved permanently to a new web address.

If i telnet the server then its not able to connect but if i use openssl
s_client -connect it shows the certificate information.
Any suggestion?


Symptoms you are describing are very strange. It is unlikely that 
telnetting to HTTPS port (which basicaly just opens TCP connection) 
won't work, while connecting with openssl (which opens TCP connection 
AND starts HTTPS handshake) does work.


Could you test one more time, and send us exact commands you used, and 
exact output you got. Also, send us Tomcat log messages so we could 
verify HTTPS APR connector port.


-Ognjen

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

Re: Need help setting up SSL on Tomcat 8

[Ognjen Blagojevic]

Sean,

On 13.7.2016 21:56, Sean Son wrote:

Thank you for your answer guys. Is there anywhere in the Tomcat config
files that I would need to specify the DNS name?  Like in Apache we
would specify the DNS name in a Virtualhost.


Take a look at context xml, attribute "name" in Host element [1], and 
attribute "defaultHost" in Engine element [2].


-Ognjen

ps. Please, write your answers below the quotes, that is standard on 
Tomcat mailing lists.


[1] http://tomcat.apache.org/tomcat-8.0-doc/config/host.html
[2] http://tomcat.apache.org/tomcat-8.0-doc/config/engine.html

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

Re: Need help setting up SSL on Tomcat 8

[Ognjen Blagojevic]

Sean,

On 12.7.2016 14:49, Sean Son wrote:

Hello thank you for your response. I am currently only accessing the
server using IP address only. We do not have a DNS record set up for the
server as of yet. It will be something like webapp.example.com


Once there is a DNS record in place, and you access your server using 
FQDN, your error will be gone.


If you are the only one who access the server, and you find that warning 
particularly annoying, you may enter FQDN and IP address in hosts file, 
and access server using FQDN, before your DNS admins do their job.


-Ognjen


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

Re: Need help setting up SSL on Tomcat 8

[Ognjen Blagojevic]

On 11.7.2016 16:29, Sean Son wrote:

Here is the certificate path:

- Go Daddy Root Certificate Authority - G2
   - Go Daddy Secure Certificate Authority - G2
  - *.example.com 



That looks Ok.

Did you, perhaps, tried to access server on subdomain of example.com? 
Wildcard certificate "*.example.com" is valid for "www.example.com", but 
not for "www.department.example.com".


-Ognjen



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

Re: Need help setting up SSL on Tomcat 8

[Ognjen Blagojevic]

On 7.7.2016 23:17, Daniel Savard wrote:

Certificate Error
There are issues with the site's certificate chain
(net::ERR_CERT_COMMON_NAME_INVALID).

Looks like adding the keyAlias to the connector did not fix anything
unfortunately.






Did you examined the received certificate in the browser. Usually this help
to identify why it failed. In this case, the chain of certification seems
to be the problem.


+1

What is your certification path / certificate hierarchy?

In Firefox: click on padlock icon, click on arrow, More information, 
View Certificate, Details, Certificate Hierarchy


In Chrome: click on padlock icon, Details, View Certificate, 
Certification path.


-Ognjen



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

Re: Need help setting up SSL on Tomcat 8

[Ognjen Blagojevic]

Sean,

On 5.7.2016 17:14, Sean Son wrote:

Hello Daniel and all

Here is the output.. the full output

http://pastebin.com/AQckw6ig


Keytool output indicates that there are two entries in keystore:

1. Entry with alias "root", created Jun 16, 2016, which is intermediate 
certificate for Go Daddy:


Owner: CN=Go Daddy Secure Certificate Authority - G2 ...
Issuer: CN=Go Daddy Root Certificate Authority - G2 ...

This is "trustedCertEntry", which means that it does not contain a 
private key, and therefore may not be used for encryption necessary for 
TLS / HTTPS communication.



2. Entry with alias "{b81d8607-57e9-4c35-a058-cd46099e7797}", created 
Jun 16, 2016. This is certificate for domain example.com, signed by Go 
Daddy:


Owner: CN=*.example.com, OU=Domain Control Validated
Issuer: CN=Go Daddy Secure Certificate Authority - G2, ...

This is PrivateKeyEntry which means that it contains private and public 
key pair, and since owner is different from issuer it means it also 
contains associated certificate. This entry may be used to encrypt data 
for TLS / HTTPS communication.



Therefore, you must point Tomcat to use second entry from your keystore. 
Try adding keyAlias="{b81d8607-57e9-4c35-a058-cd46099e7797}" to your 
connector configuration.


-Ognjen



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

Re: Source IP filtering on some URLs before Container-managed authentication

[Ognjen Blagojevic]

Andre,

On 20.11.2015 17:44, André Warnier (tomcat) wrote:

Well, you can use a lot more conditions in urlrewrite filter, such as a
client IP + URL patterns + lots more. And you can combine them using the
type="next".

Your original post said "My webapp have a set of resources, let's call
that set R. Some of those resources need to be accessed only from
certain source IP addresses, let's call that subset R'. And some subset
of R' (let's call it R'') needs authentication."

So if I get this correctly,
for R'' you have 3 requirements :
- a URL matching R'' (check with "request-url" or "request-uri")
- a remote IP (check with "remote_addr")
- an authenticated user (check with "remote_user" not blank)
  and if it does not match the last 2, return "not found" or "forbidden"
or a login page
  (or anything else that strikes your fancy)


Thanks for calrifying. I am using urlrewritefilter, for some basic 
stuff, but I will take a look if it can also be used for this scenario.


-Ognjen

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

Re: Source IP filtering on some URLs before Container-managed authentication

[Ognjen Blagojevic]

Andre,
Chris,

On 20.11.2015 9:30, André Warnier (tomcat) wrote:

On 19.11.2015 21:26, Christopher Schultz wrote:

I think that may be the only way to do it. IIRC, someone did some work
to allow Filters to be used in the valve chain, but I don't think there
is any facility for specifying s for those.


Or, you could switch from container-based AAA, to application-based AAA.
You can create a servlet filter which "wraps" your application(s), and
in it apply any rules you want.  This is totally portable, not
Tomcat-specific, and doesn't require any change to server.xml for
instance (nor to your application).


Thank you both for looking into this.

Ok, so it is a choice, either
- move RemoteAddrFilter to become a Realm in front of Authenticator 
Valve, or

- move Authenticator valve to become a Filter behind RemoteAddrFilter.



To avoid having to redo what others have already done, you may also want
to have a look at : http://tuckey.org/urlrewrite/manual/3.0/#filterparams
  see :  element
--> remote-addr  (for instance)

(I'm not saying that urlrewrite fills /all/ your needs, but you could
combine urlrewrite with some simple code of your own, to fill all your
needs. (snip)).


This part I don't get. What is the added value of using urlrewrite 
compared to RemoteAddrFilter? It is basically the same functionality?


-Ognjen

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

Source IP filtering on some URLs before Container-managed authentication

[Ognjen Blagojevic]

Hi,

My webapp have a set of resources, let's call that set R. Some of those 
resources need to be accessed only from certain source IP addresses, 
let's call that subset R'. And some subset of R' (let's call it R'') 
needs authentication.


I have a reqirement to check source IP address before authentication.

Right now, R' is specified in web.xml RemoteAddrFilter s, 
and R'' is specified in web.xml  s.


The problem is, filters are executed after container-managed 
authentication, so login form is presented to the user before 
RemoteAddrFilter kicks in, and check source IP address. That is not what 
I need. Users outside trusted IP ranges should not be able to even know 
about the protected resources, let alone to guess passwords.


RemoteAddrValve, on the other hand, is called before container-managed 
authentication, but it does not allow specifying s.


What would be a good solution for the above requirement? Extend 
RemoteAddrValve with the ability to specify s?


-Ognjen

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

Re: Question for posgresq, and jdbc.jar placement.

[Ognjen Blagojevic]

Jose & Chris,

On 21.10.2015 20:47, Christopher Schultz wrote:

Jose,

On 10/21/15 7:33 AM, Jose María Zaragoza wrote:

IMHO

$CATALINA_HOME/lib  would be the right place


+1


Are you willing to elaborate why do you prefer $CATALINA_HOME instead of 
$CATALINA_BASE?


I don't have multiple Tomcat instances running, but I still split 
$CATALINA_HOME and $CATALINA_BASE to different directories in order to 
make Tomcat upgrades easier. Everything that is different from original 
installation goes to $CATALINA_BASE (bin/setenv.sh, conf/*, logs, 
webapp, etc... as well as additional jars including lib/(jdbc).jar. Thus 
when I upgrade Tomcat and change $CATALINA_HOME I don't have to think 
about additional jars.


-Ognjen

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

Re: How do LockOutRealms work ?

[Ognjen Blagojevic]

Mark,

On 31.8.2015 12:42, Mark Thomas wrote:

I experienced situations where the user calls the first level service desk and 
a ticket goes all its way to someone who can read the server logs and 
understand the issue... Not exactly optimal.


I agree. That is why most organisations provide self-service password
reset options that are linked off the login page. After a few failed
attempts to login the user simple resets their password (within whatever
rules the organisation requires) and carries on.


How would that help? The username is still locked out. Even with the new 
password, user is still unable to log in.


-Ognjen

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

Re: Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

[Ognjen Blagojevic]

Diarmuid,

On 27.8.2015 22:31, dmccrthy wrote:

* our non-production server with the same versions of all client software
connects with no errors to a non-production instance of the same 3rd party
service using the same cipher suite. So the tool we're using is our 3rd
party client Web app (the Tomcat client). It shows the same negotiation
from TLSv1.2 down to TLSv1. My reading of your comments is that the
truststore/keystore has no bearing here because it's an outgoing client
connection and there are no inbound connections at play.


There are too many differences between working and non-working 
environments: client, firewall and server. Could you narrow that down? 
Could you connect from non-production client to production server, and 
vice versa? Could you move production client to non-production firewall, 
or non-production client to production firewall?


-Ognjen

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

Re: Need configuration example for Tomcat 7.0.55 TLS configuration

[Ognjen Blagojevic]

On 7.4.2015 15:23, Christopher Schultz wrote:

After a weekend of ripping out clumps of my hair and swearing at my
computer, nothing had worked.   In desperation, before upgrading
Java and Tomcat, I tried regenerating my self-signed certificate
with new settings (SHA256 instead of SHA1) and that seems to have
solved the problem.Moral of the story:   Take browser error
messages with a large grain of salt.


The cipher-mismatch was probably solved by something you changed in
your configuration. Re-generating the TLS certificate might have ended
some of the warnings about certs with a SHA-1 signature, but the
cipher-mismatch is a different beast and probably more important.


+1

I just tested Firefox connecting to server that serves SHA-1 
certificates, and Firefox issues no warning (except in a web console), 
let alone to refuse the connection.


-Ognjen

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

Re: Need configuration example for Tomcat 7.0.55 TLS configuration

[Ognjen Blagojevic]

Tom,

On 5.4.2015 3:06, Tom Williamson wrote:

I would like to know if anyone has a working example of getting TLS 1.2
working on Tomcat 7.0.55, so that it can be accessed by the latest
version of Chrome and Firefox.


Which version of Java do you use? Make sure it is Java 7 or 8, and if 
you already didn't upgrade, then upgrade to the latest released version.


Could you clarify do you need TLSv1.2 only, or you need TLSv1.2 among 
other TLS versions (v1 and v1.1)?




Connector port=8484 protocol=HTTP/1.1 SSLEnabled=true
   maxThreads=150 scheme=https secure=true
   keystoreFile=/path/mykeystore
   keystorePass=password
   clientAuth=false
   sslProtocol=TLS
   sslEnabledProtocols=TLS /


By specifing protocol=HTTP/1.1 you are using connector auto-detection. 
Depending on the existance of Tomcat native DLL, Tomcat will 
automatically select between APR connector and JSSE connector. Those two 
connectors have completely different set of options. The options you are 
using (keystoreFile, keystorePass), are clearly indicating you wish to 
use JSSE connectors. Therefore, to rule out present and future 
auto-detection problems, I would recommend that you explicitly specify 
connector you wish to use. E.g. for JSSE BIO connector that would be:


  protocol=org.apache.coyote.http11.Http11Protocol


Next, sslEnabledProtocols should specify exact TLS versions, so if you 
need only TLSv1.2 use:


  sslEnabledProtocols=TLSv1.2

and if you need e.g. all three versions, then omit attribute 
sslEnabledProtocols, or use:


  sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2



So far based on the Tomcat 7.0 docs, I have tried the following
configuration changes:

sslEnabledProtocols=TLS
sslEnabledProtocols=TLSv1
sslEnabledProtocols=TLSv1.1
sslEnabledProtocols=TLSv1.2
sslEnabledProtocols=TLSv1.1,TLSv1.2


Except for the first one, all other examples should be working.



With most of these, I don't get any error in the console (I have logging
set to ALL), but I also have not been able to get either Chrome or
Firefox to connect.

I have also tried various combinations of sslProtocols= and cipher=,
also with no luck.

Can anyone post a sample connector configuration that works?


Try this:

Connector port=443
   protocol=org.apache.coyote.http11.Http11Protocol
   SSLEnabled=true
   maxThreads=150 scheme=https secure=true
   clientAuth=false
   keystoreFile=/path/mykeystore
   keystorePass=password
   sslProtocol=TLS
   sslEnabledProtocols=TLSv1.2 /

BTW, the attribute name is ciphers, not cipher.

-Ognjen

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

Re: SSL / TLS compression | SPDY service|CVE-2012-4929

[Ognjen Blagojevic]

Rahul,

On 27.3.2015 14:42, Rahul Kumar Singh wrote:

So how to disable compression and / or the SPDY service in tomcat6.


If you are using JSSE connectors (BIO/NIO/NIO2), compression is already 
disabled because JSSE does not support it, and there is no support for 
SPDY protocol on those connectors.


If you are using APR/Native connector, if you didn't explicitly enabled 
it, SPDY is disabled by default. You may disable TLS compression using 
APR/Native connector parameter SSLDisableCompression=true.


-Ognjen

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

Re: Chrome reports Tomcat hosted sites as using 'obsolete cryptography'

[Ognjen Blagojevic]

Egor,

On 26.3.2015 21:23, Mark Thomas wrote:

On 26/03/2015 17:30, Egor Philippov wrote:

Anyone familiar with the warning or know
whether it represents a real security problem?


That depends on your definition of 'real'. I'm not aware of any viable
attacks but general opinion is that now is the time to take action.

Check your server certificate. The most likely explanation is that it
has a SHA-1 signature. Your CA should be able to provide you with a
replacement with a more secure signature. I know the CAs the ASF uses
have been offering this for 6 months or more.


+1

More info here:

https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know

-Ognjen

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

Re: Changing Tomcat's SSL ciphers

[Ognjen Blagojevic]

Eric,

On 2.3.2015 23:45, Eric wrote:

I am trying to change the ciphers that my Tomcat 7 server supports. I am
using the APR connector. Here's the connector information in server.xml
with the line saying which ciphers to support:

 Connector port=8443 executor=edgeExecutor maxHttpHeaderSize=32768
enableLookups=false disableUploadTimeout=true
connectionTimeout=3000
socketBuffer=122880
maxKeepAliveRequests=1
scheme=https secure=true
SSLProtocol=TLSv1
SSLEnabled=true
SSLCertificateFile=/etc/tomcat/star_mydomain_com.crt
SSLCertificateKeyFile=/etc/tomcat/star_mydomain_com.key
SSLCACertificateFile=/etc/tomcat/DigiCertCA.crt /
SSLCipherSuite=ECDHE-RSA-AES128-GCM-SHA256

...

apache-tomcat-7.0.32-ak.9.x86_64 (apparently our own custom RPM of
Tomcat, could it be that an option was turned off that prevents changing
the SSL cipher? How would I check?)



ECDHE-RSA-AES128-GCM-SHA256 is TLSv1.2 protocol [1].

In order to utilze TLSv1.2, you need to:

1. Use tcnative 1.1.32 or later.
2. Use Tomcat that supports it (8.0.15+, 7.0.57+).
3. Set SSLProtocol=TLSv1+TLSv1.1+TLSv1.2
4. Put SSLCipherSuite inside Connector tag (you put it outside).

-Ognjen

[1] https://www.openssl.org/docs/apps/ciphers.html#TLS-v1.2-cipher-suites


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

Re: Cannot disable SSL v3

[Ognjen Blagojevic]

Deepak,

On 17.10.2014 19:13, dku...@ccilindia.co.in wrote:

How can I know which protocol support my JVM.
We are using java1.7.0_40


Take a look at:

  https://wiki.apache.org/tomcat/Security/POODLE



Please let us know is any turnaround in my server.xml configuration to
disable SSL v3.


Please read cerfully the above wiki entry, and what Chris alredy wrote, 
and send us your updated connector configuration.


-Ognjen

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

Re: Tomcat 6 SSL issue

[Ognjen Blagojevic]

Baran,

On 16.10.2014 19:20, Baran Topal wrote:

I did the new CSR with the new private key.


Ok.



You could also add protocol attribute to force JSSE connector (BIO or
NIO), to prevent connector auto-selection.
1) What is the protocol attribute and where to add it?


To your Connector configuration:

http://tomcat.apache.org/tomcat-6.0-doc/config/http.html



2) I think those old cer and crt is not applicable anymore. Correct?


If you generated new key pair, and got new certificate, then yes, old 
certificates may be discarded.




3) So, what is the fundamental difference in cer and crt? I received cer as
my friend told me it's the intermediate one, whereas crt is not.


File extensions are not completly standardized. So I cannot tell what do 
those files contains. You should be able to open them and check it out 
for yourself. They usually contains certificates in Base64 or binary format.




4) What would be aliases for cer and crt? Any alias is fine? or it must
match with the alias for private key?


I am not completely sure what exactly is your question.

Any alias is fine for Tomcat JSSE connectors, but it must match the name 
from server.xml.


When importing certificate reply into the Java keystore, you should take 
care that you import it with the same alias the key pair is generated.


-Ognjen

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

Re: Tomcat JVM Crash

[Ognjen Blagojevic]

Chad,

On 10.10.2014 18:12, Chad Maniccia wrote:

I have reported my findings to Oracle. They need to fix the bug, but for us the 
best solution was just to move away from JSSE and switch to APR OpenSSL which 
is the recommend solution to begin with.


Thank you for reporting that back to us.

Could you also send bug ID, so other interested Tomcat users may keep 
track of the problem?


-Ognjen

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

Re: Tomcat 6 SSL issue

[Ognjen Blagojevic]

Baran,

On 10.10.2014 21:06, Baran Topal wrote:

Then I received 2 files from the certificate authority, abc.com.cer
and abc.om.p7b


What certificates do those files contain?



Connector port=443
maxHttpHeaderSize=8192 maxThreads=150 minSpareThreads=25
maxSpareThreads=75 enableLookups=false
disableUploadTimeout=true acceptCount=100
scheme=https secure=true SSLEnabled=true
clientAuth=false sslProtocol=TLS
keyAlias=server keystoreFile=/path/to/JKSfile/your_site_name.jks
keystorePass=your_keystore_password /


Attribute maxSpareThreads is not listed in docs:

  http://tomcat.apache.org/tomcat-6.0-doc/config/http.html

You could also add protocol attribute to force JSSE connector (BIO or 
NIO), to prevent connector auto-selection.




To clean the things up, I want to delete my keystore but is it fine if
I generate the key with another alias, e.g. tomcat as in the tomcat
documentation?


Private key necessary for encryption is in your keystore. If you delete 
your private key, and generate new key pair in new keystore your signed 
certificate becomes worthless. You will need to ask your CA (and, 
possibly, pay) for another certificate.


If you just want to rename key in keystore, use keytool -changealias.



2) I have the files, cer and crt (p7b), so is fine or should I need stg extra?


You would need complete certificate chain in order to set up HTTPS. You 
need to check do you have a complete chain in cer file or not.




3) Is the order of import important?`first crt then cer?


If you have the complete chain in cer file, then you will just import 
the cer file.




4) What are the correct import commands? Should I trust tomcat
documentation or authorities documentation?


In what parts the two are different? You should use keytool -importcert 
command.


-Ognjen

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

Re: tomcat crash problem (INTERNAL)

[Ognjen Blagojevic]

Subbu,

On 6.10.2014 10:27, bala-subrahmanyam.bha...@telenor.com wrote:

Could you please suggest one best open source java profiler for analysing and 
monitoring the tomcat server.


I don't know which (open source) one is the best, but you may try your 
luck with:


1. MAT (http://www.eclipse.org/mat/), which analyzes heap dumps. Just 
dump the server memory while the server is running and later open dump 
files with MAT.


2. VisualVM can monitor your server memory usage, measure surviving 
generations, and compare memory snapshots -- so you could detect what is 
causing memory leak.


-Ognjen

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

Re: Tomcat 8.0.14 - doesn§t start from Netbeans 8.0.1 IDE

[Ognjen Blagojevic]

Mitko,

On 3.10.2014 8:52, Mitev, Mitko wrote:

Tomcat 8.0.12
:noJuliConfig
set JAVA_OPTS=%JAVA_OPTS% %LOGGING_CONFIG%

Tomcat 8.0.14
:noJuliConfig
set JAVA_OPTS=”%JAVA_OPTS% %LOGGING_CONFIG%”


Actually, the qotation marks in 8.0.14 are in different position:

set JAVA_OPTS=%JAVA_OPTS% %LOGGING_CONFIG%



Removing quotation marks solves the problem.

Does anybody knows the reason why the quotation marks were introduced?


Rationale for the question marks is described here:

  https://issues.apache.org/bugzilla/show_bug.cgi?id=56895

-Ognjen

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

Re: tomcat crash problem (OPEN)

[Ognjen Blagojevic]

Subbu,

3.10.2014 9:38, bala-subrahmanyam.bha...@telenor.com wrote:

I upgraded tomcat from 5.0.28 to 6.0.36, after upgrade tomcat server is 
consuming lot of memory and once if memory reaches to 3GB then it is crashing 
(max memory I configured is 3GB).


What kind of a crash is that? Does JVM crashes (look for a file named 
hs_err_pid*), or Tomcat (look at Tomcat logs)? Send us the log files.


We need more information before we can diagnose the problem.

-Ognjen

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

Re: tomcat crash problem (INTERNAL)

[Ognjen Blagojevic]

Subbu,

On 3.10.2014 10:25, bala-subrahmanyam.bha...@telenor.com wrote:

Hi Ognjen,

Tomcat is crashing with the below error message.

java.lang.OutOfMemoryError: GC overhead limit exceeded


Please, reply below the quotes, it is standard on this list.

Tomcat have small memory footprint, way below 3 GB you allocate for JVM. 
So, it is probably your application data filling this 3 GB of memory. 
The above error says that garbage collector is struggling to release the 
memory, but it consumes to much CPU cycles and releases too little 
memory. This usually results in dramatic server slowdowns, so JVM 
decides to throw an error and inform you about the problem.


You should analyze your application heap usage with the profiler to 
determine what objects are holding references so GC is unable to free 
more memory. If you don't need those objects, clear the references. If 
you really need all those objects, throw more memory at the server.


Please read:

  http://wiki.apache.org/tomcat/OutOfMemory

-Ognjen

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

Re: question on certificate use - resending with attachment descriptions in case they get stripped out again. If this doesnt work I will resend the email when I get home

[Ognjen Blagojevic]

Ray,

On 1.10.2014 21:05, ray.d...@usbank.com wrote:

Loaded the website and let the error popup happen once, then I install
the certificate it prompts about (to my truststore).


If you mean that you imported CA-signed certificate to your Java 
keystore where your private key is already stored, using keytool, then, 
everything should be Ok.


If you have done something else, please explain what.

-Ognjen

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

Re: question on certificate use - resending with attachment descriptions in case they get stripped out again. If this doesnt work I will resend the email when I get home

[Ognjen Blagojevic]

Ray,

On 30.9.2014 20:54, ray.d...@usbank.com wrote:

Connector
port=443 maxThreads=200
scheme=https secure=true SSLEnabled=true
  keystoreFile=C:\Bonaire\REVPORT\.keystore keystorePass=changeit
  keyAlias=tomcat2
  proxyName=revport-it.us.bank-dns.com proxyPort=443
/

And then on the browser, when I try to load the site, I get a blank
screen again, says Internet Explorer cannot display the webpage.


If I use tomcat as the alias in my connector, the site loads but then
I get the Certificate Error  popup again, which is what I need to get
rid of (on the top right the Internet Explorer).


It seems that you created key pair under alias tomcat and imported 
certificate reply from your CA under alias tomcat2. That is wrong. You 
should be importing certificate reply under same alias as you generated 
key pair.


Here is exceprt from Oracle keytool docs:

You import a certificate for two reasons:

to add it to the list of trusted certificates, or

to import a certificate reply received from a CA as the result of 
submitting a Certificate Signing Request (see the -certreq command) to 
that CA.


Which type of import is intended is indicated by the value of the -alias 
option:


If the alias does not point to a key entry, then keytool assumes 
you are adding a trusted certificate entry. In this case, the alias 
should not already exist in the keystore. If the alias does already 
exist, then keytool outputs an error, since there is already a trusted 
certificate for that alias, and does not import the certificate.


If the alias points to a key entry, then keytool assumes you are 
importing a certificate reply.


-Ognjen

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

Re: a problem: tomcat exits unexpectedly

[Ognjen Blagojevic]

Zhao,

On 19.9.2014 3:42, bo zhao wrote:

but I can't find any error message in the log? what causes the tomcat to
pause and stop?


One of the suspects for restarts and shutdown seems to be the class 
com.jd.clover.center.service.AbstractScheduleTaskProcess, as there is a 
log message regarding it, at the first line of each log excerpt you sent.


What is AbstractScheduleTaskProcess class for?

-Ognjen


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

Re: Deploy application as Root

[Ognjen Blagojevic]

Kiran,


Question I have is that if I upload war file via manager app, where does it
go ?


It goes to appBase (e.g. direcotry webapps) as war file, and if 
neither unpackWARs at Host element nor unpackWAR of Context element is 
set to false, they are unpacked to the directory of the same name 
(e.g. webapps/ROOT.war is unpacked to directory webapps/ROOT).




I can understand that ROOT goes to the ROOT folder if I delete the root
folder, how about myapp.war ?


myapp.war will be extracted to directory myapp.



Does it go to work folder ?


All web applications are unpacked to appBase folder. Work folder is 
internal Tomcat folder.



On 12.9.2014 4:22, Kiran Badi wrote:

However I have another application which I will be deploying in the same
tomcat.

This will be basically myapp2.war ,so how do I manage this deployment so
that whenever someones gives www.myapp2.com, it should open up ?

I assume we cannot have 2 root deployment in the same tomcat.


You need to create two webapps directories, e.g. webapps-myapp1 and 
webapps-myapp2, and configure two Host elements in server.xml 
accordignly, e.g.:


  Host name=www.myapp1.com appBase=webapps-myapp1 ...
  Host name=www.myapp2.com appBase=webapps-myapp2 ...

Then you may deploy two ROOT.war files to two different webapps folders.

If you want to use Manager application for each of your virtual hosts 
you need to copy directory webapps/manager/ to both 
webapps-myapp1/manager/ and webapps-myapp2/manager/.


-Ognjen

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

Re: stress testing tomcat applications

[Ognjen Blagojevic]

Elias,

On 11.9.2014 2:03, Elias Kopsiaftis wrote:

My best guess is that tomcat doesnt like to accept requests coming for two
different logins from the same IP and same program. Is that accurate? Is
anything else that could be going wrong here?


Tomcat should allow multiple sessions from same IP without problems.

Please state which exact version of Tomcat do you use. There are plenty 
of them.


What is the number of active sessions when you start experiencing errors?

Do you have Manager element in your context.xml or server.xml defined? 
Does that element have maxActiveSessions attribute?


I recommend to implement HttpSessionListener in your application and log 
session creation and destruction to understand at which point in time 
the sessions are destroyed.


-Ognjen


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

Re: Deploy application as Root

[Ognjen Blagojevic]

Kiran,

On 11.9.2014 5:52, Kiran Badi wrote:

I am trying to deploy application as ROOT.war in tomcat  7.50 provided by
hosting service provider, but for some reasons I get below message

FAIL - War file ROOT.war cannot be uploaded if context is defined in
server.xml


I have below in server xml,


Host name=Myapp.com appBase=path  to public_html folder
   Aliaswww.myapp.com/Alias
   Aliasmyuserid.myhostingprovider.com/Alias
   Context path= reloadable=true docBase= path to
public_html debug=1/
   Context path=/manager debug=0 privileged=true
   docBase=path to /tomcat/webapps/manager
   /Context
/Host


You seem to specify the same directory for Host's appBase and Context's 
docBase. That is wrong.


AppBase is a place where you will be putting your web applications (.war 
files or directories). On default Tomcat installation that is webapps 
directory.


DocBase is a place where single web application resides. It may be 
relative to AppBase (e.g. ROOT), or absolute (e.g. 
/usr/local/tomcat/webapps/ROOT).


The two should not point to the same directory.


Next, configuring contexts in server.xml is not recommended [1]. You 
should remove Context elements from your server.xml, and move them to 
/META-INF/context.xml in web applications. If you do that, also remove 
docBase attributes.


-Ognjen

[1] 
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Defining_a_context


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

Re: Context parameter override?

[Ognjen Blagojevic]

Andre,

On 10.9.2014 18:43, André Warnier wrote:

Otherwise, my customer sysadmins would have to unpack the WAR, edit
web.xml to insert their specific values, and re-pack the WAR.  Which
they do not like to do either.

My customers also do not like a solution consisting in having these
parameters defined somehow as JVM properties that must be given on the
java command-line, because then any user with a console on the server
can see them by doing a simple ps -ef.


Could you move client specific parameters to context.xml (appname.xml)? 
Then, your client could keep the appname.xml at 
$CATALINA_BASE/conf/[enginename]/[hostname]/ directory, and replace war 
file with new versions? There is no need to unpack and repack the war file.


-Ognjen


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

Re: JSSE or APR

[Ognjen Blagojevic]

John,

On 20.8.2014 18:08, John McLean wrote:

I used the following ubuntu guide to create my csr:

https://help.ubuntu.com/12.04/serverguide/certificates-and-security.html


If you followed steps from that guide you now might have:

1. Private key in PEM format (e.g. server.key)
2. Certificate signing request (e.g. server.csr)
3. Signed certificate from your CA in PEM format (e.g. cert-server.pem)
4. Optionaly, one or more files for certificate chain in PEM format 
(e.g. chain-server.pem).


YMMV for filenames.

Those files may be used directly in APR connector configuration, or they 
may be imported into keystore for JSSE connector configuration.


For JSSE connectors you may use one of two different file formats: 
PKCS#12 or JKS.




This used openssl so does than mean I'm using APR?


We cannot tell you what connector are you using. You should know that. 
Did you configure server.xml? Which connector did you declare in server.xml?


If you didn't declare HTTPS connector in server.xml, then you probably 
still don't have HTTPS enabled. You should read about connector 
specifics, and decide which connector suits you.


Once you select proper connector you may use aforementioned files (or 
derived keystore) to configure your APR or JSSE connector.


If you need help with that, let us know.

-Ognjen

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

Re: JSSE or APR

[Ognjen Blagojevic]

On 21.8.2014 10:24, Ognjen Blagojevic wrote:

For JSSE connectors you may use one of two different file formats:
PKCS#12 or JKS.


That would be, keystore file formats.

-Ognjen

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

Re: New User Help

[Ognjen Blagojevic]

Colin,

On 18.8.2014 4:42, Colin Kincaid Williams wrote:

I have then deployed the application war file using the manager. The
application is supposed to take json POST requests, related to a path on
the host filesystem such as /opt/app/app_data/datafile . The POST requests
work on the old glassfish deployed application. However the POST requests
do not seem to work on the tomcat deployed application. Instead I get a
403. I looked through the tomcat logs folder, but only saw the POST
request, and nothing regarding the 403. Can anybody offer some advice. I
would like to note that I had nothing to do with the development of the
application. I'm just the poor sap who has been asked to put it into
production.


Tomcat may return HTTP 403 Forbidden in several cases:

1. If web application do that explicitly, by calling e.g.:

  response.sendError(HttpServletResponse.SC_FORBIDDEN);

or

2. If web application is configured to have security constraints, and 
you provide, for instance, proper username and password but that 
username is not in proper role.


According to your web.xml, you don't have security constraints 
configured there. Therefore, I would assume that 403 was sent explicitly 
from your webapp.


That realy means that you will have to talk to developers to check under 
what conditions webapp responds with HTTP 403 Forbidden.


-Ognjen

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

Re: access non-default webapp

[Ognjen Blagojevic]

Patcharee,

On 11.8.2014 14:00, Patcharee Thongtra wrote:

I have two applications running in Tomcat 6. I made the first app as a
default web app by placing it as ROOT.war in webapps/. How can I access
the second app? Whenever I browse http://localhost:8080/the_second_app/
Tomcat thinks I will access /the_second_app part in the first app.


What makes you think that?

Did you preprely deployed context the_second_app? How do you know you did?

Did you try to access http://localhost:8080/the_second_app/? What happens?

-Ognjen

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

Re: JKS keystore password Encryption

[Ognjen Blagojevic]

Sanaullah,

On 4.8.2014 17:26, Sanaullah wrote:

I will also search the archive as well.


You may find Wiki also useful:

  http://wiki.apache.org/tomcat/FAQ/Password

-Ognjen

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

Re: Restricting SSL access within webapp

[Ognjen Blagojevic]

Chris,

On 4.8.2014 22:47, Christopher Schultz wrote:

Encryption is more expensive than /not/ encrypting, but it's much
harder on the server (many connections) than it is on the client
(single-digit). Since these days, everyone is disabling compression
for SSL, the biggest problem for a dial-up connection for SSL would be
the increased payload size.


For most use-cases, encryption is not that expensive anymore, even on 
the server-side. More info here:


http://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose

https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

-Ognjen

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

Re: TC7 and SSL Questions

[Ognjen Blagojevic]

John,

On 24.7.2014 21:11, John Smith wrote:

1. Can I specify /admin/* as a security constraint url pattern so that only
that directory runs under SSL?


Yes, you can.



2. The NIO connector is accepted for JSSE, since I'm using it already, is
there any point in not using it as my SSL connector?


If /admin has low traffic, then I would say, there is no need to use 
anything else. For high traffic TLS/SSL applications you may want to do 
some performance measurements of different Tomcat connectors, simulating 
your traffic patterns.




3. Any known issues with routing 443 to 8443 in Iptables?


I recommend using JSVC instead of iptables redirect. I had issues with 
redirect when used with virtual hosts. IPv6 (ip6tables) doesn't support 
redirect, either.




4. The admin tools share underlying classes with the rest of the web
application, which is why it makes sense to have it just as a subdirectory
in the same webapp. But would I be better off migrating the admin tools to
their own webapp for the purposes of SSL?


Yes, I think so. From the security standpoint, that is way better. It 
will be much easier to apply IP address filtering, move it to another 
port / server, to isolate admin and user privileges, and so on.


-Ognjen

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

Re: How to monitor performance of tomcat

[Ognjen Blagojevic]

Randhir,

On 21.5.2014 14:31, Randhir Singh wrote:

I had changed catalina.sh in our development environment like a week back
and want to implement it in the production environment but I got this
doubt. I feel catalina.sh is invoked by startup.sh but am not sure. I have
already taken downtime for production tomorrow but I got this doubt whether
changing the


1. Don't post the same message twice. It makes volunteers on the list 
waste their time.


2. Don't top post. Bottom posting is the standard on this list.

3. Don't request/ People are volunteering here.

4. In default Tomcat instalation, catalina.sh is called from startup.sh.

5. Regardless of do you call startup.sh or catalina.sh, environment 
variables have the same meaning: JAVA_OPTS is used on Tomcat startup and 
Tomcat shutdown, while CATALINA_OPTS is only used on Tomcat startup. If 
you place -Xms2048m in JAVA_OPTS it will reserve 2 GB on Tomcat startup, 
and another 2 GB when you invoke Tomcat shutdown. That is waste of 
memory. Use CATALINA_OPTS instead.


6. It is not recommended to modify startup.sh or catalina.sh ever. All 
environment variables should be set in the file bin/setenv.sh.


7. (5.) and (6.) were already pointed out by Chris. Please read answers 
on the list carefully to show that you respect resources volunteers are 
allocating for you for free.


8. You may invoke ps -fHA | grep Bootstrap after you start Tomcat, to 
see if your CATALINA_OPTS reached JVM call.


-Ognjen


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

Re: catalina.out is 13G

[Ognjen Blagojevic]

On 22.4.2014 16:22, Filip Hanik wrote:

http://www.tomcatexpert.com/knowledge-base/rotating-catalinaout-log-files


Also, there is a related issue in Bugzilla, to make things easier to 
configure:


  https://issues.apache.org/bugzilla/show_bug.cgi?id=53930

-Ognjen


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

Re: Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x

[Ognjen Blagojevic]

Andre,

On 12.4.2014 0:51, André Warnier wrote:

Ognjen Blagojevic wrote:

On 11.4.2014 10:52, André Warnier wrote:

3) if he has recorded past encrypted traffic to/from your server, and
saved
this recording, then he can at any time go back and decrypt this past
traffic, and pick up
anything interesting from there, even without having the new keys.  Such
a recording could contain, for example, any number of submits
from HTML login pages, which were theoretically protected by being made
on an encrypted
channel. That could probably also contain any communications which your
server did with other servers over encrypted channels.


... unless Forward secrecy was utilized, which is pretty much invented
to defeat future decryption of recorded traffic.

Forward secrecy was easy to set up on Linux with APR.



All agreed. But I was talking about existing recordings of past
communications.
Whatever is done from now on, would not help in that respect, would it ?


I was also talking about past recordings. For example, let's say that 
you had a new server set up in e.g. the beginning of 2013, and you 
configured HTTPS (TLS) to support Forward Secrecy from start. And let's 
say, that some agency immediately started recording all your encrypted 
traffic, with the idea that if will be able to decrypt it in the future. 
And let's assume that the same agency found out about Heartbleed bug at 
the beginning of 2014, before general public. So they obtained 
immediately your private key. You find out about the same bug in 
7.4.2014, and you replace your private key at the same day.


Now, it is clear that the agency was able to decrypt traffic from the 
beggining of 2014 (using MITM attack), but it should also be clear that 
although they have private key of your server, and they have recorded 
all your conversations ever, they will not be able to decrypt 
conversations from 2013.


-Ognjen

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

Re: Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x

[Ognjen Blagojevic]

On 11.4.2014 10:52, André Warnier wrote:

3) if he has recorded past encrypted traffic to/from your server, and saved
this recording, then he can at any time go back and decrypt this past
traffic, and pick up
anything interesting from there, even without having the new keys.  Such
a recording could contain, for example, any number of submits
from HTML login pages, which were theoretically protected by being made
on an encrypted
channel. That could probably also contain any communications which your
server did with other servers over encrypted channels.


... unless Forward secrecy was utilized, which is pretty much invented 
to defeat future decryption of recorded traffic.


Forward secrecy was easy to set up on Linux with APR.

When tcnative 1.1.30 is released, it will be easy to set up on Windows 
with APR.


If issue 55988 [1] is resolved, it would be also possible to set it up 
on JSSE connectors with Java 8.


-Ognjen

[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=55988

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

Re: Does the HeartBleed vulnerability affect Apache Tomcat servers using Tomcat Native?

[Ognjen Blagojevic]

Chris,

On 9.4.2014 7:22, Christopher Schultz wrote:

- -1

Switching to JSSE only stops the hemorrhaging. You should consider all
your server keys compromised if OpenSSL 1.0.1 was used (prior to g
patch level). If you switch to JSSE, your key may already have been
compromised, so the switch does not protect you.

If you were lucky enough to have been ignored by Internet miscreants,
then switching will protect you, but it's a bad bet. The better bet is
to upgrade ASAP to a 1.0.1g version of OpenSSL and then re-key everything.

Then change all your passwords. :(


I agree. What I was supposed to say is: After you revoke certificates, 
and reissue a new one, you may switch to JSSE connector, and then, wait 
for patched version of tcnative dll. Thank you for pointing that out.


-Ognjen

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

Re: [OT] HeartBleed bug

[Ognjen Blagojevic]

André,

On 9.4.2014 9:49, André Warnier wrote:

I wonder if I may ask this list-OT question to the SSH experts on the
list :

I run some 25 webservers (Apache httpd-only, Tomcat-only, or Apache
httpd + Tomcat).
I do not use HTTPS on any of them.
But I use SSH (OpenSSH) to connect to them over the Internet for support
purposes, with authorized_keys on the servers.
Are my servers affected by this bug ?
Or is this (mainly) an HTTPS-related affair ?

I mean : I will update OpenSSH on all my servers anyway.  But do I have
to consider that, with a non-negligible probability, the keys stored on
my servers are already compromised ?


This is OpenSSL 1.0.1--1.0.1f vulnerabilty, so any protocol using 
OpenSSL implementation of TLS/SSL protocol (if OpenSSL libarary version 
is in mentioned range) is vulnerable, like: STARTTLS extension for 
protocols like SMTP, POP, IMAP, XMPP, FTP, LDAP, NNTP, and also other 
protocols which uss TLS/SSL like SSL VPN, and HTTPS.


SSH protocol does not use TSL/SSL, so it is not vulnerable to Heartbleed 
bug.


-Ognjen


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

Re: [OT] HeartBleed bug

[Ognjen Blagojevic]

Chris,

On 9.4.2014 14:53, Christopher Schultz wrote:

My recommendation would be to treat everything OpenSSL touches as
tainted and re-key anyway.


[I will assume we are talking about OpenSSH implementation.]

That dependins of the definition of what OpenSSL touches. OpenSSL 
consists of two libraries: libcrypto and libtls. OpenSSH implementation 
depends on OpenSSL package, but only to utilize primitive crypro 
functions from libcrypto library. Libtls library contains implementation 
of TLS protocol, including Heartbeat functionality, but OpenSSH does not 
utilize that library, AFAIK. Therefore, I stand by my earlier position 
-- no need to rekey SSH keys.


-Ognjen



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

Re: Does the HeartBleed vulnerability affect Apache Tomcat servers using Tomcat Native?

[Ognjen Blagojevic]

On 8.4.2014 18:48, Arlo White wrote:

Are Apache Tomcat servers using Tomcat Native  APR vulnerable to the
HeartBleed OpenSSL bug, or does this layer insulate them?
http://heartbleed.com/


They are vulnerable. There is no layer to insulate.

You may test with:

  http://filippo.io/Heartbleed/

I tested with Tomcat 8.0.5 with tcnative 1.1.29, which includes OpenSSL 
1.0.1e, on Windows 7 64-bit, and it confirms the vulnerability.


JSSE Connectors are not vulnerables so, one possible workaround is to 
swich to NIO or BIO connector until patched version of tcnative is 
available.


-Ognjen

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

Re: Windows tcnative openssl ciphers question

[Ognjen Blagojevic]

Jeffrey,

EECDH/ECDHE is disabled in tcnative-1.dll. There is already a request to 
enable it. Take a look at:


  https://issues.apache.org/bugzilla/show_bug.cgi?id=55915

-Ognjen


On 8.4.2014 0:07, Jeffrey Janner wrote:

Ok, this is a question for the native libs builders (or whoever knows the 
answer).
Environment:  Windows Server 2008 R2, Tomcat 7.0.50 w/APR 1.1.29, Java 1.7.0_51 
 (all 64-bit)
I'm trying to set up a ciphers list that will get me an A rating on Qualys' 
SSL testing tool.
I'm using the latest list suggested by MozillaWiki:
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK

However, when I run the test tool, it reports that the server is only 
supporting the following list:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA

Notice, none of the ECDHE-based ciphers are showing up in the list.  This is 
apparently what is keeping me from getting that perfect score, as IE wants 
those ciphers for Forward Security.   It ends up taking one of the lower 
ciphers on the list.
Does anyone know, is there a setting that needs to be made to enable those 
ciphers?  Were they turned off in the dev stage?  Is it related to my 
certificate?
Running the openssl.exe that comes with the APR binary download shows the ECDHE 
ciphers in the list.
Any help appreciated.




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

Re: Valid certificate chain failing with unable to find valid certification path to requested

[Ognjen Blagojevic]

On 4.4.2014 5:23, Toby Lazar wrote:

I've run my client program with the -Djavax.net.debug=all option. First it
listed out all of the trusted authorities. Mine is GoDaddy and this is the
record:



That one is not the issuer of your certificate.  GoDaddy has many issuing
certificates.  The GoDaddy certificate the client trusts expires in 2034
whereas your issuer certificates expire in 2031/2037.  Also, the DNs are
different.  Better to identify the trusted certificate by serial number and
subject key identifier.


+1.

It seems to be known issue with GoDaddy G2 certificate:

http://stackoverflow.com/questions/18746565/godaddy-ssl-cert-not-working-with-java

[GoDaddy] have 2 CA servers, one called Class 2 CA and the other called 
G2 CA. Their Class 2 CA signs all SHA-1 certificates, while the G2 CA 
signs all their SHA-2 certificates. This is where the problem lies - 
GoDaddy has not added their newer G2 CA server to the default java 
truststore - causing default java installations to not trust it's 
authority, and hence, does not trust your chained certificate. The 
work-around until GoDaddy adds the G2 CA server to the default 
truststore is to simply rekey your cert using SHA-1 as-to get a cert 
signed by the Class 2 CA server. Rekeying is free for GoDaddy customers 
until your cert expires (obviously).


FTR, GoDaddy or any other CA can't just add certificate to Java root 
certificates, but it must apply at Oracle for inclusion.




This is what I think is the relevant part:
[3]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
   CA:false
   PathLen:2147483647
]


It just says that server certificate you have cannot be used to sign 
other certificates, nothing else. That is irrelevant for you.



-Ognjen

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

Re: Tomcat 6 SSL CA Certificate does not work, but Self signed Certificate does

[Ognjen Blagojevic]

Mark,

On 4.4.2014 23:00, Mark Murphy wrote:

So let me try to understand what is going on here. I generate a keystore
using keytool, that contains a key. At this point it is equal to a self
signed certificate, and it works, but the browser complains that there is
no CA.


(Standard on this list is to answer below the quote.)

By using keytool -genkeypair you generate keypair -- a private key and a 
public key. Public key is stored inside self signed certificate. Both of 
them (private key and public key inside certificate) are stored in the 
keystore that may be in various formats.




I then need to create a certificate request ad send that off to
goDaddy. What is this? a public key that matches up with the private key?


It is a public key, plus information identifying server (or individual) 
packed in one message that CAs understand.




Then I have to import the certificates that goDaddy returns to me because
that validates the private key that is already in the keystore?


First of all, you must use the same keystore you used to generate 
keypair. Then, you will most probably need to import root and 
intermediate certificates first to your keystore. Then, you need to 
import server certificate, using the same keystre and the same alias you 
used to generate keypair in the first place. If you do everything right, 
that final call to keytool -importcert will replace self signed 
certificate from your keystore with a new certificate chain.


-Ognjen

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

Re: Tomcat 6 SSL CA Certificate does not work, but Self signed Certificate does

[Ognjen Blagojevic]

Mark,

On 4.4.2014 23:54, Mark Thomas wrote:

The CA that signed your certificate might not be one of the root CAs
trusted by the user agent. Most likely it is an intermediate CA. The
root CA will have signed the intermediate CA's certificate and the
intermediate CA will have signed your certificate. In practice, there
can be several layers of intermediate CAs. What you end up with is a
trust chain from the Root CA to your certificate. To make it easier for
the browsers to validate, you need to be able to provide all of these
certificates as part of the SSL handshake. Therefore you CA will tell
you that you need to import 1 or more additional certs into your keystore.


Few additional notes:

If root certificate is in Java system keystore then there is no need to 
import root certificate. If not, a user must import it, either in system 
keystore or user keystore.


Order of imports is important. You first need to (optionally) import 
root certificate, then intermediate certificates (if any), and server 
certificate in the end. Messing up import order may cause server serving 
incomplete certificate chain. Incomplete chain, though not recommended, 
may serve its purpose for some browsers. Other clients (like Java) will 
fail. Browsers have means to reconstruct incomplete certificate chains, 
but this shuldn't be relied upon.


-Ognjen


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

Re: Valid certificate chain failing with unable to find valid certification path to requested

[Ognjen Blagojevic]

Chris,

On 4.4.2014 16:27, Christopher Schultz wrote:

So they don't have a big Daddy certificate that has signed all of
their intermediate certificates? Boo. That would fix nearly everything.


Actually, having different root certificates, one for SHA-1, and one for 
SHA-2 is recommended migration practice in order to dicth all SHA-1 
certificates at some point in time, for security reasons.




FTR, GoDaddy or any other CA can't just add certificate to Java
root certificates, but it must apply at Oracle for inclusion.


If the problem is that the client trusts GoDaddy's ROOT certificate
and the server's certificate was signed by GoDaddy's intermediate
certificate (which should have been in turn signed by the ROOT
certificate), then the solution is to include the intermediate
certificate (or certificates... some CAs have longer chains) in your
keystore and configure Tomcat to serve both the server's cert and the
intermediate cert.


Configuration for JSSE connectors is somewhat different than APR. For 
JSSE, you don't configure Tomcat to serve intermediate certificates, but 
you import them to your keystore before you import server certificate. 
By doing so, JSSE will serve the complete certificate chain to the client.





This is what I think is the relevant part: [3]: ObjectId:
2.5.29.19 Criticality=true BasicConstraints:[ CA:false
PathLen:2147483647 ]


It just says that server certificate you have cannot be used to
sign other certificates, nothing else. That is irrelevant for you.


Depending upon where this came from (there was no context given), you
are correct. If this is information from the GoDaddy certificate, then
it's likely an intermediate certificate and not a root cert.


x.509v3 Basic Constraints CA:true means that the certificate may sign 
other certificates. It would be impossible that GoDaddy signing 
certificate (either root or intermediate) have CA set to false. 
Therefore I assumed the information is about server certificate.


-Ognjen


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

Re: Valid certificate chain failing with unable to find valid certification path to requested

[Ognjen Blagojevic]

On 4.4.2014 0:27, Toby Lazar wrote:

As others have noted here on other threads, you can use:

http://portecle.sourceforge.net/

to see exactly which certificates your server is providing clients (Examine
SSL/TLS connection).  Viewing server certificates via browsers can be
misleading since they don't distinguish within the chain between
certificates provided by the server and those already trusted by the client
(browser).


You also may double check your chain using other online tools like:

  https://www.ssllabs.com/ssltest/
  http://www.digicert.com/help/

I never used SSLShopper, so I don't know how reliable it is.


Another way to check certificate chain directly in server keystore is

  keytool -list -keystore server.jks -v


To check Chris' assumption about missing ROOT certificate on the client, 
you may turn on TLS debugging on the client using JVM option


  -Djavax.net.debug=all

At start it will print all root certificates trusted by the client. It 
may reveal that your system ROOT CA list on the client is outdated, 
messed up, or overriden with e.g. JVM option -Djavax.net.ssl.trustStore. 
It will also print TLS handshake details.



Jefferey:
  The hostname (www.xx.net) is correctly listed in the 
certificate. Common name: www.x.net

  SANs: www.xx.net, xx.net

Check if your Java code indeed uses one of those URL's listed in the 
certificate (www.xx.net, xx.net), and not some third one 
not listed in the certificate, or IP address.


-Ognjen

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

Re: Generate pkcs12 certificates from offical COMODO certs

[Ognjen Blagojevic]

Frank,

On 15.2.2014 7:02, Frank BONNET wrote:

seems to work without it !


I recommend that you always import intermediate certificates into the 
keystore. If you don't, some clients / web browsers will find a way to 
lookup for missing certificates, but others will fail.


Therefore, it is much better if you serve the complete chain (server 
certificate + intermediate certificates) to the client.


If you are not sure if certificate chain served to the clients is 
complete, there is plenty of on-line tools to check that for you.


-Ognjen

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

Re: Generate pkcs12 certificates from offical COMODO certs

[Ognjen Blagojevic]

Frank,

On 14.2.2014 14:10, BONNET, Frank wrote:

I have officials certificates for apache2 from COMODO that I would like to
import into  tomcat (  pkcs12 ) if someone has links / infos to do this task
it would be a great help ( google doesn't help much )


You didn't mention if you have any preference whether you want to use:

i. BIO or NIO HTTPS connectors (based on JSSE), or
ii. APR HTTPS connector (based on OpenSSL).

Since you mentioned that you want to use PKCS#12 format, I guess you are 
interested in JSSE connectors. If you want to use APR, then the 
procedure is different then the one described here.



Let's say that you have

1. Server key in file server.key
2. Server certificate in file server.pem
3. Intermediate certificates in file intermediates.pem

Then, all you need to do is:

openssl pkcs12 -export -out keystore.p12 -name myserver -in server.pem 
-inkey server.key -certfile intermediates.pem



Note that it is not necessary that intermediates.pem contains root 
certificate.



Then, configure HTTPS connector in conf/server.xml as

Connector port=443
   protocol=org.apache.coyote.http11.Http11Protocol
   SSLEnabled=true maxThreads=150 scheme=https
   secure=true clientAuth=false sslProtocol=TLS
   keystoreFile=keystore.p12 keyAlias=myserver
   keystoreType=pkcs12 /


I also recommend that if you check your ciphers strenth, and restrict 
them accordingly.


-Ognjen


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

Re: Generate pkcs12 certificates from offical COMODO certs

[Ognjen Blagojevic]

Frank,

On 14.2.2014 15:00, BONNET, Frank wrote:

the intermediate cert in the one named chain right ?


Yes, it is usually named that way.

-Ognjen



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

[OT] Re: Tomcat JDBC Error

[Ognjen Blagojevic]

Leo,

On 27.1.2014 18:17, Leo Medina wrote:

Can you please elaborate more as to what you meant by:  com.mysql.jdbc.Driver
must be present in one of your webapps. I'd expect
it to be in a JAR that has mysql in the name. If you don't need it remove
it.  I meant that we don't have a mysql db.  in our original integration.
  You also mention that it *must* be present, yet if I don't need it to
remove it.  Sorry a little confused on that statement, can you please
clarify.


The phrase it must be means it is very probably or it is most likely.

Therefore:

It must be present, you should remove it

means

It is most likely present, you should remove it.


Let's face it -- English is a crazy language:

  http://www.wordsmith.org/awad/english8.html

-Ognjen



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

Re: Weird certificate situation -- I don't even understand why it works at all!

[Ognjen Blagojevic]

James,

On 21.1.2014 0:14, James H. H. Lampert wrote:

It seems that one of our customers moved their server to a different
physical box, over the weekend, and we're now seeing some definite
weirdness:

Their Tomcat now shows a certificate that expired this past September.

But it gets weirder:

Their connector for port 443 in server.xml shows a word as the alias.
The word we usually use when setting up a customer's SSL.

But when I examine their keystore in Keytool, it shows the digit 1 as
the only alias in the keystore.

Why would this even work at all?


Hard to say without seeing your server.xml. I could only guess: you 
misspelled keyAlias attribute name, so Tomcat just reads first key in 
the keystore.


-Ognjen

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

Re: Weird certificate situation -- I don't even understand why it works at all!

[Ognjen Blagojevic]

Mark,

On 21.1.2014 9:55, Mark Thomas wrote:

Why would this even work at all?


Hard to say without seeing your server.xml. I could only guess: you
misspelled keyAlias attribute name, so Tomcat just reads first key in

the keystore.


It would be worth checking if the keyAlias atribute had any effect at all if 
there is only one key in the key store.


Checked, it does have effect. With just one key aliased tomcat in 
keystore, and attribute keyAlias=foo on connector, Tomcat throws 
exception:


java.io.IOException: Alias name foo does not identify a key entry

-Ognjen

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

Re: Cannot connect from outside using Tomcat 7/APR/SSL on AWS Windows system

[Ognjen Blagojevic]

Jeffrey,

On 19.1.2014 6:03, Christopher Schultz wrote:

Connector address=10.4.1.20 port=443 maxHttpHeaderSize=8192


Could it be as simple as having set the address attribute?


+1

BTW, setting attribute preverIPv4Stack=true on server side doesn't mean 
anything for the client. The client will try to connect with the 
protocol he prefers. The client may also fall back to other protocol 
(e.g. if IPv6 connection fails several times, try with IPv4).


I see that access log is not configured. Is there a reason for that?

Without access log you can't tell if the remote request reaches Tomcat 
or not. So, for start, I suggest you configure access log for Tomcat 7 
and report back if something is logged after you try to connect from the 
remote host. Note that Tomcat may postpone writes to the log files, so 
make sure you stop Tomcat before you check your logs.


If there is no record of remote requests in Tomcat 7 access logs, I 
suggest you analyze what is going on with Wireshark or some other packet 
analyzer. You can that see if the client:


1. tries to connect using IPv6 or IPv4,
2. is falling back,
3. which exactly IPv4/v6 adress does it use,
4. is TCP three-way handshake successfull.

Only when you confirm that three-way handshake is succsessful and that 
the destionation IP adress is IPv4 10.4.1.20, you may say that the 
request should have reached Tomcat.


-Ognjen


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

Re: SSL certificates

[Ognjen Blagojevic]

Miten,

On 17.1.2014 14:33, Miten Mehta wrote:

The catalina.out complaines with SSL handshake stating No Name matching
mhoodws.ril.local found.


For security reasons, CA shouldn't sign any certificate containing 
internal server name (either as CN, or subjectAltName):


As of July 1, 2012, all CAs were required to notify customers applying 
for internal name certificates that the use of such certificates has 
been deprecated by the CA / Browser Forum and that the practice will be 
eliminated by October 2016.


https://cabforum.org/internal-names/

So, I guess your CA removed subjectAltName while signing the 
certificate, and also missed to notify you about the removal.


-Ognjen


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

Re: SSL certificates

[Ognjen Blagojevic]

On 17.1.2014 19:14, James H. H. Lampert wrote:

At this point, if you haven't already done so, I would strongly suggest
getting your CA's tech support in on this.


+1

Reserved IP addresses and internal server names are not unique on the 
Internet, so the certificates for them may be reused in different 
places, which is a security problem. Imagine you get a certificate for 
IP 192.168.0.1 or for internal server name server.local, or worse, 
wildcard certificate *.local. That certificate may be reused on any 
local network that uses that same IP address or server name, for e.g. 
man-in-the-middle attack. The user of such network will hardly notice 
that the certificate is from completely different network.


Therefore I believe that it is reasonable for any CA to treat internal 
server names and reserved IP addresses as two faces of the same problem.


However, on second reading I noticed that Baseline Requirements say that 
CAs shall sign the certificate with either or both of them, but that 
certificate must expire before 1 November 2015. So check your CSR 
expiration date and, as James recommends, your CA's policy on that matter.


-Ognjen

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

Re: Symantec SSL cert in tomcat 6

[Ognjen Blagojevic]

Gene,

On 3.1.2014 14:55, Gene Matthews wrote:

Thie symantec instructions say to ensure the alias for the ssl cert has an 
Entry Type of PrivateKeyEntry.  Mine DOES NOT.  Instructions say if it does 
not, to please import the certificate in the “Private Key” alias.


With JKS keystore you must keep private key and certificates in the same 
keystore. Therefore, you shouldn't import server certificate and inter. 
certificates into brand new keystore, but into the old keystore -- the 
one you used to create key pair, and to generate CSR.


I find it strange that Symantec/Verisign didn't mention that explicitly 
in their documentation.




It also says to ensure the Certificate chain length is 4.


Once you import certificates into the right keystore, check that again.



PS:  How does one search the archives of this list?  When I browse the archive 
site I don’t see a search field anywhere.  So I’ve been googling without coming 
up with a solution. it is probably out there but I don’t know enough to 
recognize it :-(


http://tomcat.apache.org/lists.html

Search for Archives.

-Ognjen

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

Re: Symantec SSL cert in tomcat 6

[Ognjen Blagojevic]

Martin,

On 4.1.2014 0:27, Martin Gainty wrote:

With JKS keystore you must keep private key and certificates in the same
keystore.



MGSince A pfx that Verisign provides contains key and cert
MGWindows servers use .pfx files to contain the public key files (your SSL
  Certificate files, provided by DigiCert) and MGthe associated private key
  file (generated by your server as part of the CSR).

MGperhaps you are referring to the key/certificate combination in pfx?


No, not really. We are talking about Tomcat and JKS, not Windows servers 
and pfx.


-Ognjen

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

Re: JSVC error

[Ognjen Blagojevic]

Vicky,

On 31.12.2013 11:16, vicky wrote:

./startdaemon.sh: line 13:  7429 Segmentation fault  (core dumped) ./bin/jsvc -cp 
$CATALINA_HOME/bin/bootstrap.jar:$CATALINA_HOME/bin/tomcat-juli.jar -outfile 
$CATALINA_BASE/logs/catalina.out -errfile $CATALINA_BASE/logs/catalina.err 
-Dcatalina.home=$CATALINA_HOME -pidfile $CATALINA_PID 
-Dcatalina.base=$CATALINA_BASE 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 
-Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties 
org.apache.catalina.startup.Bootstrap start


That is a bug in daemon 1.0.14. It is resolved in daemon 1.0.15. More 
info here:


https://www.mail-archive.com/dev@tomcat.apache.org/msg72208.html
https://issues.apache.org/jira/browse/DAEMON-291
https://issues.apache.org/bugzilla/show_bug.cgi?id=54890

-Ognjen

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

Re: ssl_error_internal_error_alert in tomcat 7‏

[Ognjen Blagojevic]

Jaya,

On 20.12.2013 16:52, jaya ravindran wrote:

That means server can do TLSv1. Then why can't it connect with TLS protocol on 
browsers.


You may want to add -Djavax.net.debug=all to CATALINA_OPTS to debug 
handshake on server side. Compare OpenSSL handshake to Firefox handshake.


Also, there are some issues with your connector config:

1. If clientAuth is set to false, you don't need truststoreFile and 
truststorePass.


2. If you configure connector to serve HTTPS, you don't need redirectPort.

3. maxSpareThreads is nonexistant attribute.

-Ognjen

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

Re: enable SSL for Tomcat

[Ognjen Blagojevic]

Sivakumar,

On 4.12.2013 12:11, sivakumar_balag...@contractor.amat.com wrote:

I need to enable SSL for tomcat in a windows server 2008. I have generated a 
certificate using the csr generated by this command: certreq -new request.inf 
request.req

(...)

I have imported this certificate to CACERTS using keytool and uncommented the 
connector configuration in servers.xml in APACHE conf folder.


You used Microsoft tool (certreq) to generate the private key and CSR, 
and Java tool (keytool) to import the certificate into Java keystore. 
That is your problem.


You need to, *either*:

1. Start from the beginning: Use Java keytool to generate private key in 
Java keystore, to create CSR, and to import certificate into that SAME 
Java keystore. You should not use cacerts file as you keystore, but 
other file for that purpose (e.g. c:\users\sivakumar\server.jks).


2. Reuse what you have so far: Find where certreq stored private key; 
export private key; import private key and certificate into PKCS 
keystore; convert PKCS keystore into new keystore in JKS format.


You should consider which one is easier for you, and then we can help 
you along the way.




Connector port=8443 protocol=org.apache.coyote.http11.Http11NioProtocol SSLEnabled=true keystoreFile=C:\Program 
Files\Java\jre7\lib\security\CACERTS keystorePass=changeit maxThreads=300 scheme=https secure=true 
clientAuth=false sslProtocol=TLS


Whatever you do, you will have to change keystoreFile attribute from 
C:\Program Files\Java\jre7\lib\security\CACERTS to e.g. 
c:\users\sivakumar\server.jks.




I didn't find any error on startup of Tomcat but still ssl is not enabled.


That is strange. What you described would result in cacerts file 
containing server certificate without the private key. Therefore I would 
expect that Tomcat complains about inability to find the private key.


Either way, cacerts file is not the right place to store server private 
key and certificate. That file should contain only certificates from 
trusted CA.


-Ognjen

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

Re: enable SSL for Tomcat

[Ognjen Blagojevic]

Sivakumar,

On 4.12.2013 14:27, sivakumar_balag...@contractor.amat.com wrote:

This csr has the DN formatted like CN=server name, OU=OU Name, O=Organization Name, 
L=Location, ST=State, C=country
which is based on the information we give while genarating the keystore.

But the signing authority in our domain accepts the dn format with cn=server 
name,ou=Devices,o=organization,c=country


Please do not top post. Reply under the quote. That is standard on this 
list.


You may try to use keytool -genkeypair -dname ...

-Ognjen


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

Re: [OT] Symantic has a first tomcat worm ;-)

[Ognjen Blagojevic]

Mark,

On 25.11.2013 11:08, Mark Thomas wrote:

Unrelated to this issue, I have recently expanded the section of the
docs that covers securing the default applications. The updates will be
in the next release. Until then you can read it via the copy of the docs
built by the CI system:
http://ci.apache.org/projects/tomcat/tomcat8/docs/security-howto.html#Default_web_applications


On a related matter, if one configure file permissions as recommended here:


http://tomcat.apache.org/tomcat-8.0-doc/security-howto.html#Non-Tomcat_settings

Manager application will be unusable for deployment by uploading .war 
files. Automatic war unpacking also won't work. What is the best 
practice for remote deployment of .war files in such environment?


I usually copy .war file to temporary dir on server using scp client. 
Then, using ssh client I extract the .war file, chown .war file and 
extracted folder, and mv .war file and extracted folder to webapps/. I 
then wait for auto deployer to pick them up. Is there a better 
alternative to that?




The one question this raises for me is should the Manager application be
limited to localhost be default? I'd be interested in the community's
views on that.


Yes. A lot of Tomcat instances I've seen run under user root. 
Unfortunately, a lot of users needs Tomcat running on port 80, and they 
don't have time or knowledge to configure jsvc or httpd. They 
unfortunately resort to running tomcat as root, forgetting that manager 
application (and all other deployed webapps) will also have root 
privileges. So, adding one more level of security by enabling 
RemoteAddrValve will help security ignorant users, and will take only 
little additional effort for admins.


I also think it would be very usefull if 401 error page for manager 
application does not example password s3cret, but randomly generated 
long password unique for every request. I guess there is a number of 
Tomcat instances out there with username tomcat and passoword 
s3cret, and that needs to be prevented.


-Ognjen

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

Re: [OT] Symantic has a first tomcat worm ;-)

[Ognjen Blagojevic]

Mikolaj,

On 25.11.2013 12:46, Mikolaj Rydzewski wrote:

On 25.11.2013 12:42, Ognjen Blagojevic wrote:


I also think it would be very usefull if 401 error page for manager
application does not example password s3cret, but randomly generated
long password unique for every request. I guess there is a number of
Tomcat instances out there with username tomcat and passoword
s3cret, and that needs to be prevented.


Can you elaborate on that?
What do you mean by randomly passwords for 401 pages?


Current 401 page for Manager application says something like:


You are not authorized to view this page. If you have not changed any 
configuration files, please examine the file conf/tomcat-users.xml in 
your installation. That file must contain the credentials to let you use 
this webapp.


For example, to add the manager-gui role to a user named tomcat with a 
password of s3cret, add the following to the config file listed above.


role rolename=manager-gui/
user username=tomcat password=s3cret roles=manager-gui/


What most users do is to copy the XML example, and paste it into 
tomcat-users.xml.


I propose that 401 page for Manager be dynamically generated, so that 
instead of occurrences of example password s3cret, it generates random 
password, different for every request which results in 401 error page. 
In that way, every security-unaware user will have unique password, and 
not s3cret.


-Ognjen

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

Re: [OT] Symantic has a first tomcat worm ;-)

[Ognjen Blagojevic]

Chris,

On 25.11.2013 20:56, Christopher Schultz wrote:

role rolename=manager-gui/ user username=tomcat
password=s3cret roles=manager-gui/ 

What most users do is to copy the XML example, and paste it into
tomcat-users.xml.


If that were the case, I would have expected to see tomcat:s2cret
listed in the worm's obvious creds list. Since it's not there, I
suppose that either it's not used very often in the wild or the
authors are not very smart.


This worm maybe does not, but I found references to that 
username/password in wordlists[1], blogs[2,3] and books[4]. For me, that 
is a sign that Tomcat should avoid using that particular example password.


-Ognjen


[1] 
https://github.com/lattera/metasploit/blob/master/data/wordlists/tomcat_mgr_default_userpass.txt
[2] 
http://www.socialseer.com/2013/07/14/watching-the-hackers-try-to-break-into-tomcat/

[3] http://x9090.blogspot.com/2012/09/a-case-study-of-tomcat-web-server.html
[4] 
http://www.amazon.com/Hacking-Exposed-Network-Security-Solutions/dp/0071780289



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

Re: PFX generation using keytool

[Ognjen Blagojevic]

Nestor,
Chris,

On 6.11.2013 22:50, Christopher Schultz wrote:

java.security.KeyStoreException: TrustedCertEntry not supported.
Entry for alias root not imported. Do you want to quit the import
process? [no]:

How can i solve this issue?


What kind of stuff can be found in your .keystore source?

If you have a TrustedCertEntry (which ought to be a client
certificate, right?) then it has no place in a keystore... that
belongs in a truststore, no?


Nestor probably have root and intermediate CA certificates imported into 
Java keystore in order to create valid certificate chain during the 
import of server certificate.


After the server certificate is imported into keystore, root and 
intermediate CA certificates are safe to remove from the keystore.




Try importing .. um, less of the source keystore?


Right, OP might:

1. Delete trusted key entries, and leave only PrivateKeyEntry, and then 
export, or
2. add option -alias foo, where foo is alias for PrivateKeyEntry 
available in the keystore.


-Ognjen

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

Re: Secure Tomcat With SSL

[Ognjen Blagojevic]

On 30.10.2013 18:41, Jeffrey Janner wrote:

Not sure where to go from here! Can anyone help? I just want to do
something basic and that issecure tomcat with a godaddy SSL cert.


First, go back and re-read the last wonderful response you received from 
Ognjen.  He is right on the money for how you last had your server.xml 
configured.  If you haven't made any changes, you need to do so.
Then, ignore the bad advice that GoDaddy is giving you, because they didn't understand that you are 
using OpenSSL, aka the Tomcat Native Libraries, aka APR, in your configuration.  Go 
back to the GoDaddy site and re-issue the signed certificate and the bundled CA certs in 
apache format and save them somewhere that Tomcat can see them.
Add the 3 SSL lines to the 2nd connector in your server.xml as Ognjen 
sugessted, and comment out the 4th connector to avoid conflicts (you didn't 
provide the port numbers for the connectors, so I can't be sure you won't have 
conflicts.)
That should do it.  And have fun.


There are actually so many questions for Chris. For starters:

1. Did someone configured this Tomcat instance before you?

2. Who added 4th connector to server.xml?

3. If the 4th connector is working, and according to log messages it 
does, then why did you add the 2nd connector?


4. If the 4th connector for some reason is not working correctly, maybe 
you should comment it out, as Jeffrey suggests, and them we could try to 
configure the 2nd connector together.


I will stop here. Before we sort out the basic stuff, I wouldn't be so 
sure what to advise you to do next.


-Ognjen

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

Re: Secure Tomcat With SSL

[Ognjen Blagojevic]

Chris,
Leo,

On 28.10.2013 18:23, Leo Donahue - OETX wrote:

I've been having some trouble lately converting keys and certs from OpenSSL
format into Java's JKS format. I follow all of the magical incantations I can 
find
online to convert key+cert into a Java keystore but I get no love. Is there a
decent guide anywhere for how to do this?


 From my book of spells.

Used this to configure SSL in Apache httpd for subversion edge.

openssl pkcs12 -export -in C:/server.crt -inkey C:/server.key -name svnedge 
-out C:/server.p12

keytool -importkeystore -srckeystore C:/server.p12 -srcstoretype PKCS12 
-destkeystore C:/svnedge.jks


During TLS handshake, server may respond with complete certificate chain 
(server certificate with all intermediate certificates) or with 
incomplete certificate chain (e.g. server certificate, without any/some 
intermediate certificates). Most servers, around 88% of them, deliver 
full certificate chain, according to research mentioned here [1].


Complete certificate chain is being recognized as valid by every client 
that implements TLS (assuming that root CA certificate is in the client 
keystore). Incomplete certificate chain may be recognized as valid by 
some TLS clients (e.g. Internet Explorer), using information from 
X.509v3 extension called Authority Information Access (AIA), or using 
previously validated certificate chains. Some clients will not recognize 
incomplete certificate chain as valid (e.g. openssl or Apache 
HTTPCommons Client). Even the same client may sometimes recognize 
incomplete certificate chains as valid and sometimes as invalid, thanks 
to caching of intermediate certificates. Therefore, it is best practice 
always to deliver complete certificate chain to the client.


Having root CA certificate in the chain is unnecessary, as it wastes 
your bandwidth during TLS handshake (your client already have root CA 
certificate in its own keystore).


Assuming that intermediate certificates (intermediates.pem), server 
certificate (server.pem) and private key (server.key) are all in PEM 
format, you need to add option -certfile to command Leo provided:


openssl pkcs12 -export -out keystore.p12 -name myserver -in server.pem 
-inkey server.key -certfile intermediates.pem



Verify that the contents of the p12 keystore with:

openssl pkcs12 -in keystore.p12 -nokeys

You should verify that the certificate chain is complete (up to, but 
without root CA certificate).


Now, you may use that keystore for BIO and NIO connectors:

keystoreFile=keystore.p12 keyAlias=myserver keystoreType=pkcs12

Or you may convert it to JKS keystore as Leo suggests.

-Ognjen

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=399324#c72

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

Re: Secure Tomcat With SSL

[Ognjen Blagojevic]

Chris,

On 28.10.2013 21:45, Chris Arnold wrote:

Let us first determine which connector do you have configured (BIO, NIO
or APR), because HTTPS configuration depends on connector type. Could
you send your server.xml with comments and sensitive information removed?


?xml version='1.0' encoding='utf-8'?
!--


Please, remove comments next time, it will make it easier for us to read.



 Connector port=xx URIEncoding=UTF-8 protocol=HTTP/1.1
connectionTimeout=2
redirectPort=x maxHttpHeaderSize=32768 /

...

 Connector port=x URIEncoding=UTF-8 protocol=HTTP/1.1 
SSLEnabled=true
maxThreads=150 scheme=https secure=true
clientAuth=false sslProtocol=TLS maxHttpHeaderSize=32768 
/

...

 Connector port=x URIEncoding=UTF-8 protocol=AJP/1.3 
redirectPort=x /

 Connector port=x URIEncoding=UTF-8 
protocol=org.apache.coyote.http11.Http11Protocol SSLEnabled=true
maxThreads=150 scheme=https 
keystoreFile=/opt/alfresco/alf_data/keystore/ssl.keystore keystorePass=kT9X6oe68t 
keystoreType=JCEKS
  secure=true connectionTimeout=24 
truststoreFile=/opt/alfresco/alf_data/keystore/ssl.truststore truststorePass=kT9X6oe68t 
truststoreType=JCEKS
clientAuth=want sslProtocol=TLS allowUnsafeLegacyRenegotiation=true 
maxHttpHeaderSize=32768 /


Ok, so you have four connectors configured. First two of them have 
attribute protocol=HTTP/1.1, which means that it will automatically 
select between APR and BIO connector. APR will be selected if apropriate 
libarary is found on the system. If not, BIO connector will be selected.


Note that you dislosed your keystore passwords on public mailing list, 
so you may consider to change them.




Here it is but you will see both being initialized:
Oct 18, 2013 8:03:58 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler [http-apr-8080]


Ok, so APR library is found, and APR HTTP connector is initialized on 
port 8080.


Second (HTTPS APR auto select) connector probably fails to initialize 
since you didn't provide necessary files containing key and certificates.




Oct 18, 2013 8:03:58 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler [ajp-apr-8009]


This is third connector in your configuration. It is used for 
communication between Apache httpd and Apache Tomcat. In case you don't 
use httpd, you may comment that one out.




Oct 18, 2013 8:03:58 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler [http-bio-8443]


This is fourth connector from your configuration, and it is BIO 
connector, since attribute protocol is set to 
org.apache.coyote.http11.Http11Protocol. It seems to be working fine.



Now you have two HTTPS connectors configured, APR (2nd in your 
configuration) and BIO (fourth in your configuration). APR fails to 
start. It is not clear from the information you provided so far are you 
trying to configure APR connector, but I will assume you do, since BIO 
connector looks configured already.


You will have to make sure that ports for APR and BIO connector differs.

Now, for APR connector, you don't need keystore, but seperate files for 
server key, server certificates, and intermediate certificates. Then add 
those attributes to APR connector:


  SSLCertificateFile=/home/tomcat/server.cert
  SSLCertificateKeyFile=/home/tomcat/server.key
  SSLCertificateChainFile=/home/tomcat/intermediates.pem

When you get APR HTTPS connector up and running, to remove weak ciphers 
from OpenSSL default configuration, I strongly suggest that you also 
restrict cipher in use, using these two attiributes to connector 
configuration (*):


SSLHonorCipherOrder=true

SSLCipherSuite=EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS

For more info on setting up APR HTTPS connector, please read:


https://tomcat.apache.org/tomcat-7.0-doc/config/http.html#SSL_Support_-_APR/Native

-Ognjen


(*) As recommeded by Ivan Ristic:

https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy#/?page=2

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

Re: Secure Tomcat With SSL

[Ognjen Blagojevic]

Chris,

On 27.10.2013 2:47, Chris Arnold wrote:

This is both possible, only if you plan to use either BIO or NIO HTTP
connector. If you plan to use APR, connector configuration is completely
different.


Not sure what either of these are. I just need secure tomcat


Let us first determine which connector do you have configured (BIO, NIO 
or APR), because HTTPS configuration depends on connector type. Could 
you send your server.xml with comments and sensitive information removed?


Also, could you send your Tomcat startup messages? Depending on your 
configuration you can find them at the console or in file 
logs/catalina*.*. We only need to see connector initialization log 
messages, like these:


??? 19, 2013 12:01:06 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler [http-apr-8080]
??? 19, 2013 12:01:06 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler [ajp-apr-8009]

In the above example, you can see that APR connector is being initialized.


If you want to find out about different connector types, you may find 
more information here:


1. 
http://people.apache.org/~markt/presentations/2009-04-01-TomcatTuning.pdf (slides 
13-20)


2. http://tomcat.apache.org/tomcat-7.0-doc/config/http.html


-Ognjen

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

Re: Secure Tomcat With SSL

[Ognjen Blagojevic]

Chris,

On 26.10.2013 23:39, Chris Arnold wrote:

Tomcat 7.0.42 on SLES11. I am following 
http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html#Configuration to secure 
tomcat. I have uncommented the SSL HTTP section. The configuration section of 
that doc, importing the certificate: i have a go daddy bundle in crt format. I 
can download the cert bundle from go daddy for tomcat but it also is a crt 
file. Do i have to run this exact command:

openssl pkcs12 -export -in mycert.crt -inkey mykey.key \
 -out mycert.p12 -name tomcat -CAfile myCA.crt \
 -caname root -chain


It looks ok to me. Does it work for you?

It will create PKCS#12 keystore file (mycert.p12), so you may:

1. add parameter keystoreType=pkcs12 to your HTTPS connector, and use 
that file, or
2. convert PKCS#12 keystore to Java Keystore format, and use default 
keystore type (JKS).


This is both possible, only if you plan to use either BIO or NIO HTTP 
connector. If you plan to use APR, connector configuration is completely 
different.


-Ognjen

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

Re: can't connect to manager application

[Ognjen Blagojevic]

Edoardo,

On 19.10.2013 0:03, Edoardo Panfili wrote:

4- second modify to server.xml
Host name=localhost  appBase=webapps
unpackWARs=true autoDeploy=true
becomes
Host name=localhost  appBase=webapps
unpackWARs=true autoDeploy=true deployXML=false


It is great that you took effort to pin-point the source of the problem. 
Often users are not willing to do that.


Now, deployXML=false instructs Tomcat to ignore context descriptors in 
directory webapps/, and to consider only those in directory conf/. That 
means that context descriptor webapps/manager/META-INF/context.xml is 
ignored, so manager application is not properly intialized.


If you want to keep parameter deployXML set to false, I believe you need 
to copy webapps/manager/META-INF/context.xml to 
conf/Catalina/localhost/manager.xml.


-Ognjen



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

Re: can't connect to manager application

[Ognjen Blagojevic]

Mark,

On 19.10.2013 17:51, Mark Eggers wrote:

On 10/19/2013 7:44 AM, Ognjen Blagojevic wrote:

If you want to keep parameter deployXML set to false, I believe you need
to copy webapps/manager/META-INF/context.xml to
conf/Catalina/localhost/manager.xml.


Yep, reproducible on Windows 7.


Thanks for verifying.

-Ognjen

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

Re: can't connect to manager application

[Ognjen Blagojevic]

On 18.10.2013 7:34, Edoardo Panfili wrote:

To rule out faulty upgrade, could you try to reproduce the problem on
clean Tomcat 7.0.42 install?

the problem was surely present with 7.0.39, the 7.0.42 is a fresh
installation for me.


Could you please clarify: does the problem exists on 7.0.42, 7.0.39 or both?

Could you provide steps to reproduce the problem on fresh 7.0.42 
installation?


I tried to reproduce with the information you provided so far, but I was 
unable. It works for me.


-Ognjen

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

Re: can't connect to manager application

[Ognjen Blagojevic]

Edoardo,

On 17.10.2013 18:45, Edoardo Panfili wrote:

Some release ago (tomcat 7.0.x sorry, I can't be more precise) all was
well also on production server. Maybe i did something wrong during an
update.


To rule out faulty upgrade, could you try to reproduce the problem on 
clean Tomcat 7.0.42 install?


-Ognjen


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

Re: Issue while using SSL with Embedded Tomcat 6.0.37

[Ognjen Blagojevic]

Chris,

On 11.10.2013 18:02, Christopher Schultz wrote:

Also, a bit of a brainstorming now: could this whole thing be IP
protocol issue? I've seen similar behavior before, albeit not in
context of SSL handshake: client tries to connect using IPv6
address, but firewall doesn't allow it, so client falls back to
IPv4 and successfully connects.


I would expect that to happen during a single run of the client. Plus,
Chirag indicated that he can see the connection occur, then fail. So
it's not a firewall, IPv4/6 issue.


I stand corrected; the symptoms are definitely different than IP 
protocol fallback.


-Ognjen

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

Re: Issue while using SSL with Embedded Tomcat 6.0.37

[Ognjen Blagojevic]

Chirag,

On 10.10.2013 6:19, Chirag Dewan wrote:

A small update. The customers client is C++ client,which uses OpenSSL. And I 
found that client hello message is SSLv2 protocol. And the server 
response(server hello) is a TLSv1 protocol. Is there something I am missing?


There is a difference in SSLv2 protocol and SSLv2Hello pseudo-protocol. 
SSLv2 is basically broken (although a lot of badly configured servers 
still support it).


SSLv3, and TLS protocol specifications allow that handshake happens in 
SSLv2 format, and then to immediately switch to SSLv3 or TLS. This is 
also known as SSLv2Hello pseudo-protocol. It is done for compatibility 
reasons, and it is considered relatively safe. It is what you are 
observing, and is perfectly normal.


In Tomcat you may specify which exact protocols to use, by setting 
sslEnabledProtocols attribute on HTTP connector (Tomcat 7/8 and Tomcat 
6.0.38+), or undocumented protocols attribute (versions prior to 
6.0.38). Those attributes may take one or more of the following values: 
SSLv2, SSLv3, TLSv1, TLSv1.1, TLSv1.2, SSLv2Hello. Of course, it is 
recommended not to use SSLv2, but you may use SSLv2Hello (among 
others), to ensure compatibility.


Note that aforementioned attributes are somehow related to attribute 
sslProtocol, which, by itself selects a group of enabled protocols.


-Ognjen

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

Re: Issue while using SSL with Embedded Tomcat 6.0.37

[Ognjen Blagojevic]

Chris,

On 10.10.2013 19:11, Christopher Schultz wrote:

Also, Chirag has the connector supporting only TLS, so SSLv2 HELLO
should indeally fail entirely.


Setting attribute sslProtocol=TLS may actually enable all protocols 
from SSLv3 to TLSv1.2, plus SSLv2Hello. Even setting something like 
sslProtocol=TLSv1.1 would enable the same group of protocols. Tomcat 
docs clearly warns about that behavior (HTTP connector):


sslProtocol - The the SSL protocol(s) to use (a single value may enable 
multiple protocols - see the JVM documentation for details).




If you really only want to use TLS but support SSLv2 HELLOs, it's not
entirely clear to me what setting you want here (sslEnabledProtocols),
with sslProtocol, etc. I suspect what you want is this:

sslProtocol=TLS sslEnabledProtocols=TLS, SSLv2Hello

Chirag, give that a try and see if your problems are solved.


That is not valid configuration. TLS is not legal value for attribute 
sslEnabledProtocols, and it will be ignored. SSLv2Hello is not legal 
without any other secure protocol so JSSE will throw an exception. 
Something like


  sslProtocol=TLS
  sslEnabledProtocols=SSLv2Hello,TLSv1,TLSv1.1,TLSv1.2

would be valid config for what you propose.

It would also help to track down the cause of the problem, if Chirag 
sends handshake logs of failing and successful handshake.


Also, a bit of a brainstorming now: could this whole thing be IP 
protocol issue? I've seen similar behavior before, albeit not in context 
of SSL handshake: client tries to connect using IPv6 address, but 
firewall doesn't allow it, so client falls back to IPv4 and successfully 
connects.


-Ognjen

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

Re: Issue while using SSL with Embedded Tomcat 6.0.37

[Ognjen Blagojevic]

Chris,

On 8.10.2013 17:40, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-

Can anyone assist me in understanding why it is failing for the
first time? And is there any way I can force the Tomcat not to
select this cipher suite? Or any other way that I can resolve this
issue.


See the Connector documentation, specifically the cipherSuites
attribute. Unfortunately, Tomcat's cipherSuites configuration is only
explicit... you can't say something like defaults without
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA.


I guess you mean ciphers (for BIO and NIO connectors) and 
SSLCipherSuite (for APR connector).


Here are examples for both.

E.g.1.

   ciphers=SSL_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

E.g.2.

SSLCipherSuite=EDH+aRSA:3DES:!RC4:!aNULL:!eNULL:!LOW:!MD5:!EXP:!PSK:!SRP:!DSS


-Ognjen

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

Re: setenv.sh issue

[Ognjen Blagojevic]

Vicky,

On 20.9.2013 11:32, vicky wrote:

Hi All,

  When i am declaring variables in my $CATALINA_BASE/bin/setenv.sh file , they 
are not getting exported :-

eg:- export NAME=e1
  export ID=22

But when i am declaring the same variables in $CATALINA_BASE/bin/startup.sh in 
following manner these are getting exported properly:-
eg:-
export CATALINA_OPTS=-DNAME=e1 -DID=22

Kindly suggest what is the issue in this


When you say varibles, do you mean Java system properties or OS 
environment variables?


If you need to set Java system properties, use:

  export CATALINA_OPTS=-DNAME=e1 -DID=22

If you want to export OS environment variables use:

  export NAME=e1
  export ID=22

In either way, refrain from modifying startup.sh, but use setenv.sh.

Regards,
Ognjen

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

Re: setenv.sh issue

[Ognjen Blagojevic]

Vicky,

On 9/20/2013 4:14 AM, vicky wrote:

I need to set certain application specific enviornment variables ,pls
suggest what is the best way of doing that.
eg:- configuring enviornment variable for LOG4j file path


1. Please, don't top post.

2. I doubt log4j will read any environment variables, and Stackoverflow 
confirms my doubts:


http://stackoverflow.com/questions/201188/using-system-environment-variables-in-log4j-xml-configuration

3. Make sure you understand the difference:

http://stackoverflow.com/questions/7054972/java-system-properties-and-environment-variables

4. Configure log4j using Java system properties, just like Mark suggested:


Mark:

JAVA_OPTS=-Dlog4j.home=$CATALINA_BASE/logs \
-Dderby.system.home=$CATALINA_BASE/databases
export JAVA_OPTS

Note that both of these could (should) probably go in CATALINA_OPTS.



-Ognjen

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

Re: Tomcat 7 SSL Setup: ERR_CONNECTION_REFUSED

[Ognjen Blagojevic]

Mavenpol,

On 16.9.2013 22:47, Mavenpol Saulon wrote:

This server where I imported the certificates and has been encountering
errors is just one of the servers that are configured to run SSL. All of
the other servers have the same setup except for the keytool -delete..
that I used in this particular erring server. Other servers are OK in SSL.

I'm worried that the keytool delete might have caused the problem?


(On this list it is standard to put your text below the quote.)

What is the content of your Java keystore now? You should have 
PrivateKeyEntry with valid certificate chain. Check it using


  keytool -list -v


You may also check if the certificate chain is served properly to the 
client using openssl:


  openssl s_client -connect server.example.com:443 -showcerts


Other than that, you may try to turn on TLS/SSL Java debugging using VM 
option:


  -Djavax.net.debug=all


These commands/option will give you some insight what is wrong with 
keystore and TLS/SSL handshake.


-Ognjen

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

Re: Tomcat 7.0.42 Won't Start

[Ognjen Blagojevic]

Ragini,

On 14.8.2013 22:53, Singh, Ragini wrote:

Now when I
place my application in the webapps folder and add the following to
server.xml, my Tomcat doesn’t start.


Adding context configuration into server.xml is discouraged. For 
alternative ways to configure context, please read:


  https://tomcat.apache.org/tomcat-7.0-doc/deployer-howto.html

This is not the source of your problem, though.



I have attached the log file with error.

(...)

Caused by: java.lang.ClassNotFoundException: 
com.es.uh.edu.EBPI.SECFORM.InitParamsMissingException


This class seems to be missing from the classpath. Do you know how to 
make sure that the class is on the web application classpath? In case 
you don't, please read:


  http://tomcat.apache.org/tomcat-7.0-doc/appdev/index.html

BTW, it is recommended that you name your Java packages in lowercase.

-Ognjen

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

Re: FW: configuring realm UserDatabase do not works

[Ognjen Blagojevic]

Francesco,

On 13.8.2013 1:01, Francesco Viscomi wrote:

When I try to access the protect resource I get:

(...)

HTTP Status 403 - Access to the requested resource has been denied


Error 403 means that user is authenticatied but not authorized (e.g. 
username and password are correct, but something is wrong with 
configuration of roles).




1)  Adding the following statement to the the tomcat-user.xml:
role rolename=UserRole/
user username=user password=uuu role=UserRole/


Here is your problem. Name of the attribute for user tag is roles, 
not role. You should change that to:


  role rolename=UserRole/
  user username=user password=uuu roles=UserRole/


BTW, this is tricky to notice, since Tomcat will not validate file 
tomcat-users.xml against a schema.


-Ognjen


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

Re: Upgrade to Tomcat 7 Issues

[Ognjen Blagojevic]

Seema,

On 12.8.2013 13:09, Seema Patel wrote:

org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot load JDBC driver class 
'com.mysql.jdbc.Driver'

...

Caused by: java.lang.ClassNotFoundException: com.mysql.jdbc.Driver


You are doing fine. You correctly removed all the jar files as Chuck 
suggested. Now you need to add them one by one EITHER to Tomcat lib 
folder or webapp WEB-INF/lib folder.


Since your configuration implies that Tomcat will be managing your DB 
connection pool, add mysql-connector jar to Tomcat lib folder, and try 
to restart Tomcat.


-Ognjen


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

Re: Downgrade Tomcat7 to Tomcat6

[Ognjen Blagojevic]

Sumilang,

On 8.8.2013 3:53, Sumilang Plucena wrote:

I have a development server Ubuntu12.10 and Tomcat-7.0.30. But prior to 
upgrading Tomcat7 from Tomcat-6.0.29 we never had problem with our website. I 
would like to know how I can go about downgrading Tomcat7 without affecting 
applications hosted by tomcat7.


Since that is your development server, how do you feel about resolving 
problems you have with Tomcat 7, rather than downgrading? Mailing lists 
are here to help you.


Upgrading and downgrading may be done in phases. You may install Tomcat 
6 and Tomcat 7 on the same server and migrate your webapps one at the time.


-Ognjen

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

Re: Remote deployments in Tomcat

[Ognjen Blagojevic]

Thulasiram,

On 6.8.2013 12:46, Thulasiram Gopalakrishna wrote:

If for some reason, the Manager application is / can not be deployed, is there 
still a way to achieve remote deployment on to Tomcat? Or is it a must, that we 
must be having Manager application deployed to deploy applications remotely?


Other than using HTTP(S) protocol to deploy your webapp using manager 
application, you may copy webapp / WAR file directly to your server 
(e.g. using scp).


-Ognjen

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

Re: LDAP/Realm with TLS in Tomcat 6/7?

[Ognjen Blagojevic]

Jens,

On 6.8.2013 12:44, Jens Neu wrote:

is there a lib/method/whatever to achieve Realm Auth in Tomcat  5.x where
username/password are protected by TLS?


I never tried it myself, but you might find these links useful:

  https://wiki.apache.org/tomcat/JNDI_startTLs_HowTo
  https://issues.apache.org/bugzilla/show_bug.cgi?id=49785
  https://www.mail-archive.com/users@tomcat.apache.org/msg80660.html



org.apache.catalina.realm.JNDIRealm works with Tomcat 5, but not in 6 :-(


JNDIRealm should work just fine in any supported Tomcat version. If you 
have any problems with it, please report it here.


BTW, if you are already upgrading, you may consider to upgrade directly 
to latest Tomcat 7, to save yourself from doing two upgrades.


-Ognjen

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

Problem with getRealPath() on Tomcat 8

[Ognjen Blagojevic]

Hi,

I am just testing Tomcat 8.0.0-RC1 that is proposed for (Alpha) release.

I noticed that (unlike Tomcat 7.0.42) this version throws 
IllegalArgumentException upon calling ServletContext.getRealPath(). It 
seems that TC8 expects that argument provided to getRealPath is 
non-empty string.


The code that tries to execute getRealPath with empty argument is not 
mine, it is from Apache Axis2 1.6.2 (latest production release). Now, I 
could file a bug with Axis2, but I am actually not sure is it really 
necessary that getRealPath argument is non-empty string?


-Ognjen


P.S. More details below.


Stack trace:

[ERROR] java.lang.IllegalArgumentException
java.lang.IllegalArgumentException
at 
org.apache.catalina.webresources.AbstractResourceSet.checkPath(AbstractResourceSet.java:39)
at 
org.apache.catalina.webresources.DirResourceSet.getResource(DirResourceSet.java:91)
at 
org.apache.catalina.webresources.StandardRoot.getResourceInternal(StandardRoot.java:176)
at 
org.apache.catalina.webresources.CachedResource.validate(CachedResource.java:62)
at 
org.apache.catalina.webresources.Cache.getResource(Cache.java:78)
at 
org.apache.catalina.webresources.StandardRoot.getResource(StandardRoot.java:163)
at 
org.apache.catalina.core.StandardContext.getRealPath(StandardContext.java:4528)
at 
org.apache.catalina.core.ApplicationContext.getRealPath(ApplicationContext.java:398)
at 
org.apache.catalina.core.ApplicationContextFacade.getRealPath(ApplicationContextFacade.java:335)
at 
org.apache.axis2.deployment.WarBasedAxisConfigurator.init(WarBasedAxisConfigurator.java:103)
at 
org.apache.axis2.transport.http.AxisServlet.initConfigContext(AxisServlet.java:584)
at 
org.apache.axis2.transport.http.AxisServlet.init(AxisServlet.java:454)
at 
org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1235)
at 
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1148)
at 
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1044)
at 
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5025)
at 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5322)
at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:726)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:702)
at 
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:698)
at 
org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:968)
at 
org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1742)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at 
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)

at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

at java.lang.Thread.run(Thread.java:724)


--

Axis2 code (WarBasedAxisConfigurator.java:103-106):

103:String webpath = 
config.getServletContext().getRealPath();

104:if (webpath == null || webpath.length() == 0) {
105:webpath = 
config.getServletContext().getRealPath(/);

106:}

--

Tomcat 8 code throwing the exception (AbstractResourceSet.java:37-41):

protected final void checkPath(String path) {
if (path == null || path.length() == 0 || path.charAt(0) != '/') {
throw new IllegalArgumentException();
}
}

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