Certificate Revocation on SAP Web Dispatcher

[Former Member]

We have recently set up X.509 Certificate based authentication. The SSL handshake is performed by the Web Dispatcher. Requests are forwarded to SAP Netwewaver 2004s Portal with the certificate in the header field. All of this works "as advertised". Certificates are created by an OpenSSL based CA with the proper extensions and are mapped to UME accounts.

Now we want add the ability to revoke certificates. One reason is, that even if a certificate is no longer mapped to an account, the Portal will still allow the user to log in and use the certificate. The certificate is not stored in the UME, but for the time of the session it looks as if the user did authenticate with a certificate.

We have added the CRL distribtion point extension ot a certificate. We can see that the CRL is downloaded from this site. It shows up in the certificate revocation service page. However, all revoked certificates still work.

The same CRL works correctly on an Apache test server. Here a revoked client certificate will already cause the SSL handshake to fail.

Does it help us to have the CRL installed to the Portal server? Or is it necessary to set up revocation on the Web Dispatcher? Does the Web Dispatcher support certificate revocation at all? If yes, where does it get the CRL from? Does the CRL have to meet certain requirements in addition to the ones defined in RFC 3280?

[Former Member]

Hi Niels,

Your question is very interesting but unfortunately, I've never read anything about certificates revocation in help.sap.com or SAP notes.

You should, maybe, ask directly the question to SAP in a support message.

If you get any answer on this I would be interested to know it because we are currently investigating the use of X.509 Certificate based authentication.

Regards,

Olivier

[Former Member]

Hi again,

Check this thread in this same forum

[Questions regarding client authentication with x.509 certificates |]

it seems that it is not supported at least by the ABAP stack.

Regards,

Olivier

[Former Member]

OSS ticket is pending.

x.509 certificate based authentication basically works. Revocation also works - kind of. The Portal will download the revocation list refered to by the CRL Distribution Point extension in the certificate (no, you can't do without. You will not be able to set up the alternative distribution point if there was not CRLdp in the certificate in the first place. Very strange!)

But if the Web Dispatcher accepted the revoked certificate for the SSL handshake, the Portal will just not authenticate the user. It will, however, allow the user to map the certificate to his account. This even seems to happen, if the CertPersisterLoginModule has been removed from the login stack. So all of a sudden the user can login with username password, and at the same time present the (invalid!) certificate to the applications...

[WolfgangJanzen]

>

> OSS ticket is pending. 
>
> But if the Web Dispatcher accepted the revoked certificate for the SSL handshake, the Portal will just not authenticate the user. It will, however, allow the user to map the certificate to his account. This even seems to happen, if the CertPersisterLoginModule has been removed from the login stack. So all of a sudden the user can login with username password, and at the same time present the (invalid!) certificate to the applications...

That indeed sounds like a bug - so it was a good idea to submit a support message.

Regards, Wolfgang

PS: I still believe that certificate revocation should be customizable on a per-application level ("application" in this context refers to "usage type": the same certificate might be used for different purposes: SSO, digital signature, encryption, S/MIME, ...). Furthermore, some of the certificate revocation mechanisms have a negative performance impact so they might be used with care. Take the payment card validation as an example: depending on the purchase amount you might be prompted for an online validation (requires to enter your PIN) and sometimes you simply need to sign-off a piece of paper - the decision is up to the shop operator and depends on the related costs (for online validation) which is comparable to "performance impacts" in our case).

[Former Member]

Dear Wolfgang,

the latest result of a long and frustrating OSS discussion is, that everyhting is fine except the "Map your certificate" message text, the solution being a more open text along the lines of "you might be able to map your certiicate, if certain technical requirements you can't possibly know about are met".

No fix to Web Dispatcher

Niels

[Former Member]

I asked a similar question recently and the answer was: Java = yes, ABAP = current no.

Perhaps an option worth looking into is a single-sign-on mechanism which deactivates the password? Then you can control the "all of a sudden" mentioned earlier by eliminating it?

Just a thought - I don't know your setup.

Cheers,

Julius

[Former Member]

Hi Julius,

we are not primarily concerned with single-sign-on. Our concern is security (2-factor authentication: something you have, something you know). Disabling the password is an option to surpress the password expiration issue, but we decided to keep the default behaviour (expired passwords must be changed, even if you log in with a certificate).

best regards,

Niels