Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
08-11-2012 03:29 AM
In Germany one can use "ELSTER" to transmit tax reports electronically to the financial authorities. Elster is build in many ERP Systems and alike.
Unfortunately the certificate used by the authorities is self signed and therefor not trusted by the PA and gets newley created by and signed by the "forward_untrust" CA in the PA rendering a communication error in the ELSTER software (which has the original certificate hardcoded).
See attached a little how-to to fix this with a "not decrypt" rule. If anyone finds a better, more granular way to accomplish this, please let me know.
08-11-2012 12:00 PM
This is certainly a valid work around and you will most likely not be able to find a better or more granular one.
The self signed certificate is not the main problem here, it could be imported into the Palo Alto as a trusted CA.
However, the server ip-addresses seem to use the same certificate (same fingerprint, same s/n) with the common name 'Elster HTTPS-Servlet' which will always result into a failed verification due to 'hostname mismatch'.
Not enough, the certificate of www.elsterft.de is expired since Dec. 19. 2011 (as of today Aug. 11. 2012)
Even if you would be able to overcome all these issues the ssl decryption will most likely still fail, because the server requires a mutual certificate authentication.
Congratulation to the German tax authorities for this great implementation and the ISO 27001 certification.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!
