Retrieving EIDAS Certificate values

[sonalishyam]

Hi,

I see Apigee provides option to retrieve standard X 509 certificate values from virtual host.

Can something similar be done for eidas certificate as well.

Also are there any performance issues in this approach?Is it better to go for custom code to retrive such values using java callout or similar .

Regards,

Sonalee Shyam

[ylesyuk]

Have you had a chance to look at https://github.com/yuriylesyuk/eidas-x509-for-psd2 git repo?

It contains Java Callout policy that processes qcStatements with PSD2 instructions of eiDAS certificate. There is a test proxy that uses the policy as well.

[sonalishyam]

Yes,how do we pass the eidas certificate to Apigee at the first place through transport layer and how to access the values from virtual host?

[sonalishyam]

@Omid Tahouri

Could you please help here

[sonalishyam]

there is no documentation available specific to EIDAS as off now

[API-Evangelist]

Hi ylesyuk,

Thanks for the proxy..

Was testing the proxy and get below error. Do we need to add any additional jars? Can you share a zip of working sample?

==

{
"fault": {
"faultstring": "org/bouncycastle/openssl/jcajce/JcaPEMWriter",
"detail": {
"errorcode": "Internal Server Error"
}
}
}

==

Thanks.

[API-Evangelist]

After adding below jars it is working..

bcpkix-jdk15on-1.56.jar

bcprov-jdk15on-1.56.jar

Thankyou.

[vinnumca]

@ylesyuk

Question:

How do you format cert with new line characters? Say we receive the cert but how do you process the received cert and format it to pass it to java code?

Parsing a certificate (check curl command)

https://github.com/yuriylesyuk/eidas-x509-for-psd2

[ylesyuk]

At the point you pass a certificate to a parser, it should have EOL after signature lines.

1.

That's the way how pem parser libs work. most of the times, you don't need \n after EVERY lineof the certificate. Only after *signature lines*, ie., ----- BEGIN CERT ---, ---- END CERT ----.

2.

https://www.ietf.org/rfc/rfc4648.txt"

3.1. Line Feeds in Encoded Data MIME [4] is often used as a reference for base 64 encoding. However, MIME does not define "base 64" per se, but rather a "base 64 Content- Transfer-Encoding" for use within MIME. As such, MIME enforces a limit on line length of base 64-encoded data to 76 characters. MIME inherits the encoding from Privacy Enhanced Mail (PEM) [3], stating that it is "virtually identical"; however, PEM uses a line length of 64 characters. The MIME and PEM limits are both due to limits within SMTP. Implementations MUST NOT add line feeds to base-encoded data unless the specification referring to this document explicitly directs base encoders to add line feeds after a specific number of characters. " So canonical max length per standard is 64 chars. many parsers tolerate lack of eol within encoded line and might even treat markers differently (ie, without eol), but strictly speaking(tm) that's where we are.

if you look at an invocation example, you can spot \n at the end of the lines.

$ curl -H 'SSL-CLIENT-CERT: -----BEGIN CERTIFICATE-----\nMIIECDCCAvCgAwIBAgIEb8KUejANBgkqhkiG9w0BAQsFADCBlDELMAkGA1UEBhMC\nREUxDzANBgNVBAgMBkhlc3NlbjESMBAGA1UEBwwJRnJhbmtmdXJ0MRUwEwYDVQQK\nDAxBdXRob3JpdHkgQ0ExCzAJBgNVBAsMAklUMSEwHwYDVQQDDBhBdXRob3JpdHkg.../9ftRm6d/DT54tCiR\nQ1q2Ca1AIXrpFAoDBAvqtQb4lyPnG6BJcwYBUg==\n-----END CERTIFICATE-----' http://$ORG-$ENV.apigee.net/eidas-parse-certificate