According to RFC 2560:
"HTTP based OCSP requests can use either the GET or the POST method to submit their requests."
I ran into issues today with windows not being able to validate certificate status via OCSP. I noticed that windows certutil sends a "GET" to my OCSP responder whereas other validation clients that use "POST" were successfull.
Looking at the logs I saw the follow for all GET requests:
"HTTP/1.1 400 Bad Request"
Adding the following line(53) to "/opt/jboss/bin/standalone.conf" in jboss 7.1.1 final fixed the problem:
JAVA_OPTS="$JAVA_OPTS -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true"
According to RFC 2560:
"HTTP based OCSP requests can use either the GET or the POST method to submit their requests."
I ran into issues today with windows not being able to validate certificate status via OCSP. I noticed that windows certutil sends a "GET" to my OCSP responder whereas other validation clients that use "POST" were successfull.
Looking at the logs I saw the follow for all GET requests:
"HTTP/1.1 400 Bad Request"
After some digging I found out that by default tomcat is configured to block URI encoded directory traversal.
Reference:
http://en.wikipedia.org/wiki/Directory_traversal_attack#URI_encoded_directory_traversal
Adding the following line(53) to "/opt/jboss/bin/standalone.conf" in jboss 7.1.1 final fixed the problem:
JAVA_OPTS="$JAVA_OPTS -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true"
Here is my test data showing the before and after packet captures
https://drive.google.com/file/d/0B8S6XVp3uXjPcHMzT2toc2NuWlU/edit?usp=sharing
Thanks, but this is already documented at http://ejbca.org/docs/installation-ocsp.html#OCSP%20th.
Perhaps a documentation note in some other place could have saved you the work? Any suggestions?
Cheers,
Tomas
Yep, it would have been helpful! I think it make sense where it is. Thanks.