I am using a Tomcat 7.0.52 server and using a hashed password in the tomcat-users.xml.
My server is accepting logins using the plain-text password and hashed password both.
How do I prevent / block users from logging in using the hashed password and force them to use the plaintext password?
Snippet of the following files
web.xml :
<login-config>
<auth-method>DIGEST</auth-method>
<realm-name>testvalue</realm-name>
</login-config>
server.xml
<Realm className="org.apache.catalina.realm.MemoryRealm" digest="SHA"/>
tomcat-users.xml
<user username="testuser" password="xxxx--------------yyyy" roles="testrole"/>
I know this isn't strictly the answer to what you asked but I would recommend upgrading tomcat to at least the latest version of 8.0 (8.0.48 at the time of posting). It's been a while since I made the upgrade from 7 to 8 but if memory serves it was pretty painless. This link should have everything you need to know about migrating up. Only thing that comes to mind that you'll really need to look out for is it requires java 7 or higher and even that shouldn't be a big issue unless you have a particularly particular setup going.
Tomcat 8.0.x Instructions Below
This is how I have mine set up and I cannot login by pasting my hashed password into the password field. I opted for sha-512 and arbitrarily picked 512 for my salt-length as well. You don't have to but why not?
Tomcat 8 - server.xml
<Realm className="org.apache.catalina.realm.LockOutRealm">
<!-- Tomcat comment stuff trimmed out here -->
<Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase">
<CredentialHandler className="org.apache.catalina.realm.MessageDigestCredentialHandler" algorithm="sha-512" saltLength="512" />
</Realm>
</Realm>
Tomcat 8 - tomcat-users.xml:
<role rolename="yourrolehere"/>
<user username="yourusername" password="yourhashedpasswordhere" roles="yourrolehere"/>
I'm sure you already know how to use digest.bat (or digest.sh if that's your thing) but for anyone else tuning in open a command prompt and navigate to your tomcat installation and into the bin directory. Then enter the following:
digest -a sha-512 -s 512 youRcl3artextpa$sword
This will produce a very long password hash in the format of:
youRcl3artextpa$sword:hashedpasswordforalongtime
Copy everything after the semi-colon and make sure it has no line breaks. (clean it up in notepad if you need to)
That's your new hashed password.
Tomcat 8 Digested Passwords Documentation
Related
A user tries to connect to a tomcat application. Her password contains the € glyph.
On other applications, it works just fine.
On our in-house application, it fails.
We use a linux box, tomcat 8.5, jdk 1.8, with -Dfile.encoding=UTF-8, Basic auth with a JNDIrealm.
The header Basic XXXXXX is good.
<Realm
className="org.apache.catalina.realm.JNDIRealm"
debug="99"
connectionURL="ldap://someurl:389"
connectionName="someName"
connectionPassword="somePassword"
referrals="follow" userBase="DC=EXAMPLE,DC=COM"
userSearch="(sAMAccountName={0})"
userSubtree="true"
adCompat="true" />
What is wrong ?
Found it. You have to use a Valve with the encoding specified.
<Valve className="org.apache.catalina.authenticator.BasicAuthenticator"
charset="UTF-8" />
See https://cwiki.apache.org/confluence/display/TOMCAT/Character+Encoding#CharacterEncoding-Q10HowtoconfiguretheBASICauthenticationschemetouseUTF-8
I’m using Tomcat 9.0.19 and trying to enable X.509 cert.-based client authentication (AKA I&A) for a particular Web application.
In summary, the Tomcat works for an application that has basic I&A enabled over one-way TLS. When accessing the Web application that has certificate-based I&A, Tomcat does not seem to request a client certificate as part of the Server Hello message, prior to sending Server Hello Done and it later fails the authentication check:
02-Jan-2020 13:00:40.371 FINE [https-jsse-nio-443-exec-10] org.apache.catalina.authenticator.SSLAuthenticator.doAuthenticate Looking up certificates
02-Jan-2020 13:00:40.830 FINE [https-jsse-nio-443-exec-10] org.apache.catalina.authenticator.SSLAuthenticator.doAuthenticate No certificates included with this request
Traced the TLS flow in Wireshark and saw the TLS 1.2 handshake. Shortly after encrypted data is exchanged, the Tomcat sends an “Encrypted Alert” message and the socket is closed. Trying to contact the Tomcat from the browser, doing a GET. The browser does not prompt me to select a certificate, which also seems to point to Tomcat not requesting it from the browser.
Any help will be greatly appreciated!
More Details:
We have a set of certificates for the Tomcat and the client, issued by an Intermediate CA, which is signed (issued) by a Root CA. The trust stores have been setup on both sides (client and server) as well as key stores with the right certs/keys in them. The Web application is setup to require certificate I&A (web.xml):
<security-constraint>
<web-resource-collection>
<web-resource-name>All by default</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>OTService</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>CLIENT-CERT</auth-method>
<realm-name>certificate</realm-name>
</login-config>
The OTService role is setup in the Tomcat-Users.xml, along with a single user account:
Now, the Connector in server.xml is configured as follows:
<Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="100" SSLEnabled="true" scheme="https" secure="true">
<SSLHostConfig>
<Certificate certificateKeystoreFile="/apache-tomcat-9.0.19/conf/km/keyStore.jks"
certificateKeystorePassword="PASSWORD"
certificateKeyAlias="tomcat"
type="RSA" />
truststoreFile="/apache-tomcat-9.0.19/conf/km/trust_store.jks"
truststorePass="PASSWORD"
truststoreType="JKS"
certificateVerification="required"
clientAuth="true"
protocols="TLSv1.2"
</SSLHostConfig>
</Connector>
Any ideas why Tomcat would not request a client certificate?
The first issue that I discovered was that Tomcat ignored the Connector->SSLHostConfig settings for the trust store and used the JRE default trust store anyway. The way I discovered it was to have a browser save the negotiated TLS session key to a file (Google SSLKEYLOGFILE), then configured the Wireshark to use that file, captured the browser-Tomcat session and then was able to see every message in plaintext.
Next, I discovered that Tomcat was actually asking for a client cert., but the list of accepted Root CAs it was sending was from the default JRE cacerts file, not from the file specified by the truststoreFile attribute. Can have Tomcat use a different file across the board by adding a setenv.sh file to the Tomcat bin directory with Java properties to override default trust store location.
Now, I was in business, the browser was able to complete the TLS handshake, but then the authentication and authorization steps were failing. I finally determinate that the proper way to provide the cert. subject field in tomcat_users.xml file was not "CN=OU Client, OU=Control Systems, O=IoTOY, L=Scottsdale, S=AZ, C=US", but "CN=OU Client, OU=Control Systems, O=IoTOY, L=Scottsdale, ST=AZ, C=US". Finally, I had 2-way TLS working.
One thing to keep in mind is if anything running on the Tomcat attempts to connect over TLS to another system that uses commercial CA certs, it will fail because the truststore you're using now does not have commercial Root CAs' certs. One way to remediate it is to make a copy of the default JRE cacerts file and add your system-specific CA cert(s) to it and point to it from the setenv.sh file noted above.
When you have:
<Connector ...>
<SSLHostConfig>
<Certificate A=1 B=2 C=3 />
D=4 E=5 F=6
</SSLHostConfig>
</Connector>
then A,B,C are attributes of the Certificate object but D,E,F are NOT attributes of the SSLHostConfig object -- they are XML content which is different. Attributes need to be put IN THE TAG:
<Connector ... >
<SSLHostConfig certificateVerification="required" truststoreFile=... >
<Certificate ...keystore... />
</SSLHostConfig>
</Connector>
and that does cert-request on the initial handshake as desired (for me, tested on tomcat 9.0.14).
I am trying to connect to tomcat with an active directory user.
When the password is in plain text like the following:
<Realm className="org.apache.catalina.realm.JNDIRealm"
connectionURL="ldap://localhost:389"
connectionName="user_name"
connectionPassword="password"
userBase="OU=blabla,DC=aaa,DC=com"
userSubtree="true"
userSearch="(sAMAccountName={0})"
userRoleName="memberOf"
roleBase="OU=blabla,DC=aaa,DC=com"
roleName="cn"
roleSubtree="true"
roleSearch="(member={0})" />
the authentication is ok. BUT, I don't want a password in my configuration file.
I tried the following:
<Realm className="org.apache.catalina.realm.JNDIRealm"
connectionURL="ldap://localhost:389"
digest="MD5"
connectionName="user_name"
connectionPassword="encrypted_password"
userBase="OU=blabla,DC=aaa,DC=com"
userSubtree="true"
userSearch="(sAMAccountName={0})"
userRoleName="memberOf"
roleBase="OU=blabla,DC=aaa,DC=com"
roleName="cn"
roleSubtree="true"
roleSearch="(member={0})" />
but the authentication fails.
I didn't find any solution.
I will really appreciate any help
thank you
I think your only alternative is to subclass JNDIRealm and make a new attribute that will have some sort of encrypted connection password. The password can't be hashed (with, e.g. MD5 as you specify) because hashes are one-way--there's no undoing a hash--and Tomcat needs the password in its original unhashed form to authenticate against the AD installation.
If you use a reversible encryption in your JNDIRealm subclass, then when Tomcat needs the password you can decrypt the password and pass it along.
I am currently trying to use embeded Tomcat for my application and am trying to set it up to get the URL of the http request.
Some Background:
I am using the same code as in the first answer for the post here : Howto embed Tomcat 6?
The only change I have made is :
private String catalinaHome = "/home/xyz/tomcat"; // This dir is created and has full access permissions
Also , I am looking at: http://tomcat.apache.org/tomcat-5.5-doc/catalina/docs/api/org/apache/catalina/startup/Embedded.html
There are no server.xml and tomcat-users.xml that I could find, so I created a tomcat-users.xml since I was getting an exception :Memory database file /home/xyz/tomcat/conf/tomcat-users.xml cannot be read .
tomcat-users.xml:
<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
<role rolename="tomcat"/>
<role rolename="role1"/>
<user username="tomcat" password="tomcat" roles="tomcat"/>
<user username="both" password="tomcat" roles="tomcat,role1"/>
<user username="role1" password="tomcat" roles="role1"/>
</tomcat-users>
The code uses container.setRealm(new MemoryRealm());
It appears from here : http://tomcat.apache.org/tomcat-4.1-doc/catalina/funcspecs/fs-memory-realm.html that I should have a server.xml file and there should already be one created by default.
1] Do I need to create a server.xml, what should be the default in it ?
I have put a file with default from here : http://www.akadia.com/download/soug/tomcat/html/tomcat_server_xml.html , but just want to know what is the right thing to do ?
2]When I access http://localhost:8089/mywebapp/index.html, all i get is The requested resource () is not available, though I have an index.html page at the "webappDir" in the code
3] My only need from the embedded tomcat is to intercept so as to get the URL passed to tomcat in my code. I can then parse the URL [do my stuff] and then create a http payload and send an http response back.
I would appreciate any pointers, especially for 3] ?
Thanks!
Ok, for your first question, yo do not need server.xml. If you check the code of your initial post they are setting the parameters there. So that is what server.xml would encapsulate. In reality what happens is that Tomcat will parse server.xml for the properties you are defining on your java file where you instanciate the catalina call to start. But since it is embedded you are setting all those parameters on you class instead.
For your second question, check your logs directory and see what is being parsed. Something is happening after your service starts because it should already redirect you once you call the port. either way, just try http://localhost:8089 and see what you get back in return from tomcat. It should give you some kind of response back from the server itself.
if you do it like this "http://localhost:8089/mywebapp/index.html" you are trying to access a created context, and that might not be configured correctly, but that is just a guess right now.
Try this first and tell me what you get back. we can troubleshoot from this point and see if I can help more in that sense.
Quick question, is this windows or linux you are installing on?
If it is linux the configurations filea are located usually on /etc/tomcat6. (at least on ubuntu they are). Reply back with the version you have installed. I might be able to help you out.
I guess I should also elaborate here a little more. Tomcat is a service in linux as well, so in ubuntu you have to start tomcat in order to access it.
$: sudo service tomcat6 start
then it starts tomcat on port 8080 (usually if not changed) of your localhost. hence you type localhost:8080 to access the website for configuration of tomcat that gives you a It works prompt for you.
Let me know if you have more questions, I will try to respond to the best of my knowledge
I'm currently working with a payment processor. I can browse to the payment URL from our server, so it's not a firewall issue, but when I try to use CFHTTP I get a I/O Exception: peer not authenticated. I've downloaded and installed their latest security cert into cacerts keystore and restarted CF and am still getting the same error. Not only have I installed the providers cert, but also the 2 other Verisign certificate authority certs in the certificate chain. The cert is one of the newer Class 3 Extended Validation certs.
Has anybody come across this before and found a solution?
A colleague of mine found the following after experiencing the same issue when connecting to a 3rd party.
http://www.coldfusionjedi.com/index.cfm/2011/1/12/Diagnosing-a-CFHTTP-issue--peer-not-authenticated
https://www.raymondcamden.com/2011/01/12/Diagnosing-a-CFHTTP-issue-peer-not-authenticated/
We used the solution provided in the comment by Pete Freitag further down the page. It works, but I think should be used with caution, as it involves dynamically removing and adding back in a particular property of the JsafeJCE provider.
For the sake of archiving, here is the original content of Pete Freitag's comment:
I've narrowed this down a bit further, and removing the
KeyAgreement.DiffieHellman from the RSA JsafeJCE provider (which
causes the default sun implementation to be used instead) seams to
work, and probably has less of an effect on your server than removing
the entire provider would. Here's how you do it:
<cfset objSecurity = createObject("java", "java.security.Security") />
<cfset storeProvider = objSecurity.getProvider("JsafeJCE") />
<cfset dhKeyAgreement = storeProvider.getProperty("KeyAgreement.DiffieHellman")>
<!--- dhKeyAgreement=com.rsa.jsafe.provider.JSA_DHKeyAgree --->
<cfset storeProvider.remove("KeyAgreement.DiffieHellman")>
Do your http call, but pack the key agreement if you want:
<cfset storeProvider.put("KeyAgreement.DiffieHellman", dhKeyAgreement)>
I figured this out by using the SSLSocketFactory to create a https
connection, which provided a bit more details in the stack trace, than
when using cfhttp:
yadayadayada Caused by: java.security.InvalidKeyException: Cannot
build a secret key of algorithm TlsPremasterSecret at
com.rsa.jsafe.provider.JS_KeyAgree.engineGenerateSecret(Unknown
Source) at javax.crypto.KeyAgreement.generateSecret(DashoA13*..) at
com.sun.net.ssl.internal.ssl.DHCrypt.getAgreedSecret(DHCrypt.java:166)
Would be great if the exception thrown from ColdFusion was a bit less
generic.
specific to coldfusion 8 with an webserver with modern ssl ciphers:
I use coldfusion 8 on JDK 1.6.45 and had problems with <cfdocument ...> giving me just red crosses instead of images, and also with cfhttp not able to connect to the local webserver with ssl.
my test script to reproduce with coldfusion 8 was
<CFHTTP URL="https://www.onlineumfragen.com" METHOD="get" ></CFHTTP>
<CFDUMP VAR="#CFHTTP#">
this gave me the quite generic error of " I/O Exception: peer not authenticated."
I then tried to add certificates of the server including root and intermediate certificates to the java keystore and also the coldfusion keystore, but nothing helped.
then I debugged the problem with
java SSLPoke www.onlineumfragen.com 443
and got
javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
and
Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be
multiple of 64, and can only range from 512 to 1024 (inclusive)
at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DashoA13*..)
at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:627)
at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:107)
... 10 more
I then had the idea that the webserver (apache in my case) had very modern ciphers for ssl and is quite restrictive (qualys score a+) and uses strong Diffie-Hellman groups with more than 1024 bits. obviously, coldfusion and java jdk 1.6.45 can not manage this.
Next step in the odyssee was to think of installing an alternative security provider for java, and I decided for bouncy castle.
see also http://www.itcsolutions.eu/2011/08/22/how-to-use-bouncy-castle-cryptographic-api-in-netbeans-or-eclipse-for-java-jse-projects/
I then downloaded the
bcprov-ext-jdk15on-156.jar
from http://www.bouncycastle.org/latest_releases.html and installed it under
C:\jdk6_45\jre\lib\ext or where ever your jdk is, in original install of coldfusion 8 it would be under C:\JRun4\jre\lib\ext but I use a newer jdk (1.6.45) located outside the coldfusion directory. it is very important to put the bcprov-ext-jdk15on-156.jar in the \ext directory (this cost me about two hours and some hair ;-)
then I edited the file C:\jdk6_45\jre\lib\security\java.security (with wordpad not with editor.exe!) and put in one line for the new provider. afterwards the list looked like
#
# List of providers and their preference orders (see above):
#
security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider
security.provider.2=sun.security.provider.Sun
security.provider.3=sun.security.rsa.SunRsaSign
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.sun.security.sasl.Provider
security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.9=sun.security.smartcardio.SunPCSC
security.provider.10=sun.security.mscapi.SunMSCAPI
(see the new one in position 1)
then restart coldfusion service completely.
you can then
java SSLPoke www.onlineumfragen.com 443 (or of course your url!)
and enjoy the feeling...
and of course
<cfhttp and <cfdocument worked like a charm and like before we "hardened" our ssl ciphers in apache!
what a night and what a day. Hopefully this will help (partially or fully) to someone out there. if you have questions, just mail me at info ... (domain above).
Did you add it to the correct keystore? Remember that ColdFusion uses it's own Java instance. I spent several hours on this once before remembering that fact. The one you want is at somewhere like /ColdFusion8/runtime/jre/lib/security/
Try with this in CMD
C:\ColdFusion9\runtime\jre\bin>
keytool -import -keystore ../lib/security/cacerts
-alias uniquename -file certificatename.cer
Note: We must choose the correct keystore present inside the security folder,as there are other keystore file present inside bin.If we will import the certificate to those key stores it will not work.
What I just found out was referenced at this article: http://kb2.adobe.com/cps/400/kb400977.html and a few other places after a lot of digging.
If you are looking at this article you have most likely inserted your "server.crt" certificate in the proper root locations and you have probably inserted it into the cacerts file in /ColdFusion9/runtime/jre/lib/security using the command
\ColdFusion9\runtime\jre\bin\keytool -import -v -alias someServer-cert -file someServerCertFile.crt -keystore cacerts -storepass changeit
(if you haven't done this, do it now).
The thing I was running into was that I am setting up ssl on my localhost so after doing these steps I was still getting the same error.
As it turns out, you need to also insert your "server.crt" into the "trustStore" file commonly located in /ColdFusion9/runtime/jre/lib using the command
\ColdFusion9\runtime\jre\bin\keytool -import -v -alias someServer-cert -file someServerCertFile.cer -keystore trustStore -storepass changeit
Hopefully this will save someone time.
I am using JRun. After trying a lot of different things I came across a snippet of information that was applicable in my setup. I had configured an (1)HTTPS SSLService with my own truststore file. This caused the piece of information in the following link to become important.
http://helpx.adobe.com/coldfusion/kb/import-certificates-certificate-stores-coldfusion.html
Note: If you are using JRun as the underlying J2EE server (either the
Server Configuration or the Multiserver/J2EE with JRun Configuration)
and have enabled SSL for the internal JRun Web server (JWS), you will
need to import the certificate to the truststore defined in the
jrun.xml file for the Secure JWS rather than the JRE key store. By
default, the file is called "trustStore" and is typically located
under jrun_root/lib for the Multiserver/J2EE with JRun configuration
or cf_root/runtime/lib for the ColdFusion Server configuration. You
use the same Java keytool to manage the trustStore.
Here is the excerpt from my jrun.xml file:
<service class="jrun.servlet.http.SSLService" name="SSLService">
<attribute name="port">8301</attribute>
<attribute name="keyStore">/app/jrun4/cert/cfusion.jks</attribute>
<attribute name="trustStore">/app/jrun4/cert/truststore.jks</attribute>
<attribute name="name">SSLService</attribute>
<attribute name="bindAddress">*</attribute>
<attribute name="socketFactoryName">jrun.servlet.http.JRunSSLServerSocketFactory</attribute>
<attribute name="interface">*</attribute>
<attribute name="keyStorePassword">cfadmin</attribute>
<attribute name="deactivated">false</attribute>
</service>
Once I imported the certificate into this truststore (/app/jrun4/cert/truststore.jks) it worked after restarting ColdFusion.
(1) http://helpx.adobe.com/legacy/kb/ssl-jrun-web-server-connector.html
Adding the cert to the keystore did not work for me on CF9 Enterprise.
Ended up using the CFX tag, CFX_HTTP5.
I realize this is a very old discussion, but since it still comes up near the top of a search for the "peer not authenticated" error in CF, I wanted to share that for most people, the simple solution is to update the JVM that CF uses. (More in a moment on how to do that.)
The cause of the problem is generally that the service BEING CALLED has made a change that requires a later version of TLS or SSL (and perhaps a change to supported algorithms). Later JVMs offer that, while earlier ones did not. Since CF runs atop the JVM, it's the calls out of CF (va cfhttp, cfldap, cfmail, etc) that "suddenly" start to fail.
And sure, sometimes a cert update is the answer (and even then, you have to do it carefully), but it's not always needed. And updating the JVM also gives other benefits, in terms of bug fixes, etc.
The only challenge is knowing what JVM your version of CF will support. (But even people still running on an old CF version have found that updating the JVM CF uses has solved this problem and not caused any others.)
I discuss all this in a 2019 post:
https://coldfusion.adobe.com/2019/06/error-calling-cf-via-https-solved-updating-jvm/
Hope that may help someone.