Description of problem:
Bug # 953200 (and equivalent wildfly bug WFLY-3580) added a certificate propagation to EJB remoting so that the X509 of the authenticated user can be passed on to downstream calls needing security context. However the certificate being used is based on the older/deprecated java API for x509 namely javax.security.cert.X509Certificate but should use the newer API java.security.cert.X509Certificate. 

We ran into issues when we tried to leverage the fix provided by WFLY-3580 via EAP 6.4 to stack the remoting login module with a custom login module uses 2 ways SSL. 
We had to add a custom method to convert the certificate being added to the request headers via the javax.security.auth.login.password and convert that to the newer API, which is more prevalent than the one deprecated. 

Version-Release number of selected component (if applicable):
EAP 6.4 (jboss-as-security7.5.0.Final included in EAP 6.4 and equivalent version in wildfly)

How reproducible:
Always reproducible if you are using a newer JAAS login module that uses 2 ways SSL that expects an X509 in the request header.

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

I have created a workaround that is named extended login module that add a utility method to convert the deprecated X509 to the newer API based x509. The code is located here https://github.com/djcldns/extended-remoting-login-module/blob/master/src/main/java/org/jboss/as/security/remoting/ExtendedRemotingLoginModule.java
I also have fork of the SSL remoting quickstart to test the fix provided. That quickstart is located here https://github.com/djcldns/jboss-secured-ejb-remote-over-ssl.

Basically the ideal fix would be to use an X509 based on the newer API as default certificate and have a utility similar to the I have so that if one is still relying on the deprecated API they can easily convert the certificate by overriding the default to match they use case.