Looking for a more elegant solution to replacing the root certificate used for Single Sign-on in the SAP landscape without having to replace certificates in the backend SAP systems in a 'big bang all at once' approach.Currently using Secure Login Server 3.0 along with Secure Login Client and passing x.509 certificates to ABAP and Java systems.

Scenario:Replacing the root certificate in Secure Login Server 3.0 with a new root certificate.This is because the old one is SHA1 which is being depcreated by the industry, creating a new one as SHA2. The replacement concept is the same as if the root certificate expired and needed replacing.

The current approach being taken is to create a new root in Secure Login Server, distribute to the clients (Windows desktops so in this case in the 'Trusted Root Certificate Authorities'), and new certificates based on the new root placed in the backend ABAP and Java systems.

This would keep the existing SSO (with old root) intact and working until all distribution is done for the new root and testing is vetted. Then cutover to the new root for users as a whole basically by switching the Authentication Profile in Secure Login Server to the new root. Later at some point, remove all remnants of the old root.

The area where this is falling down is trying to co-exist the new root certs in the backend ABAP and Java systems in addition to the already existing ones there from the old root cert.

The approach based on a suggestion in another forum was to import the new root cert into strust SNC SAPCRPTOLIB as a certificate in the certificate list, and also import the new root cert into the Java Stack as a Trusted Root CA.However, based on testing, SSO with the new root as described will not work unless the old certs are actually replaced with the new ones. Simply importing the new root cert into existing PSE for Abap or Trusted Root CA for Java does not work.Example for getting new root to work: For ABAP in strust, delete existing SNC SAPCRYPTOLIB, then import the new cert. Now new SSO works in ABAP, but old SSO is obviously broken.Same for Java backend systems. The Server Identity tab only allows one entry (NW 7.4), so if the existing entry (with old root) is replaced, the new SSO works but old SSO breaks. If the existing entry is left as is, and the new root is only imported as a Trusted Root CA, the new SSO does not work.So based on this testing, a cutover to a new root certificate would require a 'big bang all at once' process of replacing all ABAP strust certs with the new ones and same for Java stack Server Identity certs.This is not an elegant apporach and prone to issues.The Secure Login guide suggests that a new root can be rolled out in an overlapping manner with the old one, and that the old ones will not be removed until the new one is vetted. However,it does not describe the process to do so, and based on my testing does not work as suggested.

Any feedback for a better approach for migrating a root certificate in the SAP landscape would be appreciated.

Related questions

7 Answers

in general, the description Lutz has provided is correct. You can switch to another PKI (i.e. replace your Root CA, with or without changing its subject name).

The order is important:

First, create the new PKI.

Second, roll out the new Root CA certificate to all participants.

Third, enable the new PKI as issuer for new user / service / server certificates

Always care for keeping the previously rolled-out trust: both old and new Root CA certificates must be present during this smooth PKI migration. Once all participants have new PKI certificates, you may remove the old Root CA.

To avoid a disruption in STRUST / SNC or TLS, you should get the new STRUST PSE Replace Wizard (SAP Note 2414090 - STRUST wizard to replace existing key pairs). It allows to replace a PSE and get a PKI certificate without service interruption. Existing trust of the current PSE is also taken over.

Add comment

interesting observation. Your post is quite old, have you already found a solution in the meantime?

I'm pretty sure and know from my experiences, replacing a root will never need to be done in a big bang AAO approach ;-) Maybe the problems you have are caused by the fact, your Root CA names stays the same? What about renaming the new as SLS Root CA v2 or similar? That is why often a good PKI concept includes a naming and version convention for CA certificates. To import a new Root CA certificate in parallel to a existing one via STRUST or in AS Java always worked for me so far, hence I don't see a big issue here.

Add comment

No, have not yet found a better solution.I would be interested in how the concept of the parallel approach works.

The import of multiple root certificates themselves into Java for example are not an issue.I currently am testing out scenarios in java where multiple root CA's exist.

But it's in importing certificates signed by those roots, and having the ability for thosecertificate to co-exist that is an issue.Here's an example with ABAP since that has less moving parts.As mentioned, in the Secure Login Server, a new root (with a new name) has been created.Let's assume a basic SSO scenario where in ABAP strust there is an SNC SAPCryptolib PSEwith has a signed certificate from the old root. This is the 'Own Certificate'.

But in replacing that PSE (basically right click -> Replace) with a new PSE containing a signed cert from the new root, SSO based on the old root fails becasuse the old PSE is now gone.

Here's what was done:Right click SNC SAPCryptolib ReplaceSNC ID: <name>Algorithm: RSA with SHA-2Key Length: <length>Now there exists a new 'Own Certificate' that is self-signed under 'SNC SAPCryptolib'.Generate a Certificate Request and have it signed by the Secure Login Server new root.Import the Certificate Response into strust 'SNC SAPCryptolib'Now SSO based on the new root works.However, SSO based on the old root fails because the old PSE is gone.

This is where I don't see how the parallel piece works, it seems like the PSE for'SNC SAPCryptolib' only allows one 'Own Certificate'.And the one wanted long term is the new one.Because the old one contains SHA-1, it cannot stay due to Security policy as the 'Own Certificate'in 'SNC SAPCryptolib'.Would appreciate any clarification.

Add comment

No, I have not found a better solution. At the SAP IOUG Admin conference in February, I went to an 'Ask the Experts' session, but they didn't know. They acknowledged it must be a common scenario, or at least it would start to become much more common like the scenario we are both facing. They were to ask colleagues from Germany location but I've yet to get an answer.

Add comment

unfortunately I don't get what the problem is. That might be my misunderstanding. But since I also plan to replace the CA I would be glad if we could develop a common understanding.

What I plan to do for migration is:

1. Import new CA's root-certificate to all systems' certificate list of the existing (old) SNC SAPCryptolib PSE (this new CA will have a different DN than the old one). This makes all systems trust the new CA along with the old CA.

2. Import new CA's root-certificate to all clients PCs. This makes all PCs trust the new CA

Now the full environment is prepared to deal with (trust) certificates signed by the new CA as well as the old CA.

So finally:

3.a. Use new CA for client certificates

3.b. Step by step replace SNC SAPCryptolib PSE on all systems and let certificate requests be signed by new CA. Import both old CA's and new CA's root certificate into the certificate list of this new PSEs to establish trust to both old and new CA again.