It's hard to imagine anyone using any unencrypted network communication these days. Asymmetric cryptography, with SSL being its undisputed king, gives us great opportunities to design secure access to systems. SSL offers both server and client authentication to build a relationship of trust between parties. In this text, I will try to show how secure access and certificate-based authorization can work with the SAP GUI.
SAP supports the Secure Network Communication Protocol (SNC), which is based on SSL. However, it must be explicitly configured to enable secure communication between the SAP GUI and the SAP server. I will try to explain how to do this. The first step is to prepare certificates on the SAP side. For this I need a Certification Authority (CA), which has to be built from scratch in a very simplified version. This will make it possible to encrypt the communication between the client and the server. Then I will look at the possibility of authenticating the client with a certificate, which will provide SSO functionality.
There is no denying that this is a very broad topic, so expect some simplifications, especially in the CA build area. Certain topics and detailed descriptions are simply beyond the scope of the blog post. But it is also a fully functional end-to-end setup with all the necessary configuration elements.
I have prepared a completely fresh setup to ensure that all steps and configurations are included in this text. I used the ABAP Platform Trial, which provides a docker image with S/4HANA 1909, which is more than enough for this exercise. In fact, I have experience with the same configuration on many older and newer versions of SAP Netweaver/ABAP Platform, and I see no major differences in this part of the system.
I also installed a fresh SAP GUI 8.0 with two options selected:
Later I will install an additional component, but this is not required to enable SNC, so we'll do it in the SSO-related part.
What is PSE? It is a kind of a local repository that can store a private key and trusted certificates. It is used in various scenarios involving secure communication protocols such as SSL. PSE management is essential for the security of SAP systems. There are several default PSEs used by SAP system for various purposes. SNC SAPCryptolib PSE is valid for SSO.
Let's create the PSE in edit mode of STRUST transaction.
There are some details I need to fill in. The first part is related to your organization and the future subject of the certificate. The second part is more security related. It's not the place to discuss details, but today a 4096-bit RSA key seems to be a good choice.
As a result, I get the PSE, which contains a private key and a self-signed certificate.
Of course, I like to show real life scenario, so self-signed certificate is not what is expected. I need to prepare a Certificate Signing Request that can be sent to my professional CA to establish trust in my organization. Let's generate the CSR.
Then the system asks for the signature algorithm, but the PSE algorithm is fine. I don't want any alternative names either, so I just accept the defaults. The result is a certificate request that can be saved to a file or copied to a text file.
I can check how the PSE is visible at the operating system level. This is a file that can be maintained with the sapgenpse command. I can get the main certificate details, including a subject, issuer, and expiration date. The subject is the same as the issuer, so this is a self-signed certificate.
Now I need to focus on the non-SAP part of the exercise. The CSR is already in place, so the CA needs to do the signing. But I don't have a CA yet, so I need to build one.
Please note that even though I try to build the correct structure of the CA, there are simplifications in the setup. I build the CA for our exercise purposes only, without following all the security rules related to CA separation, full key management, CRL process, etc.
Let's start with the structure. We need a Root CA, which will be trusted in our organization. The root CA certificate is always self-signed and trust is established by explicitly adding the authority to the trusted list. This can be done by the administrator or by the system/software vendor. In this case, the administrator is responsible.
Then I will create two intermediate CAs: one for servers and one for users. Finally, I'll sign the sandbox server certificate with the first CA. The second CA will generate and sign a client certificate for a test user.
Once the layout is known, then the creation process can be started from the root CA. The directory structure below can help you keep things organized.
Root CA is like any other certificate, so a private key is required.
The command created a file with the key. Remember, this is the most secret file in your entire CA infrastructure. It must be kept private. Let's create a self-signed certificate based on the key.
Some option must be provided to build the subject of the certificate:
Country Name (2 letter code) [AU]:PL
State or Province Name (full name) [Some-State]:kuj-pom
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MyCompany
Organizational Unit Name (eg, section) []:Security
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:
In real life, you'll probably add a human-readable common name, but this is not mandatory. We'll differentiate the root CA by organizational unit, which is Security.
Now I have two files - one with private key, which is secret. The second one is certificate, so public part of the pair. As I mentioned earlier, the root CA is always self-signed, so there is no need to generate a CSR. Therefore, the root CA is ready. Simple, right?
As always, my first step is the creation of a private key:
The key has been generated. Here procedure differs from the Root CA, so I need to generate signing request:
I need to provide input. Please note, that this CA is distinguished by OU: Servers.
Country Name (2 letter code) [AU]:PL
State or Province Name (full name) [Some-State]:kuj-pom
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MyCompany
Organizational Unit Name (eg, section) []:Servers
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:
The interServers.csr.pem CSR file is located in the intermediateServersCA directory. It needs to be signed by our Root CA. We have everything on one server, so only one command is required:
As you probably noticed, in addition to the CSR, the root CA key and certificate were also required to complete the process. The most important thing is that I now have a signed certificate for the intermediate CA. This CA will be used to sign leaf server certificates.
You can verify that the new CA (OU=Servers) is signed by the root CA (OU=Security):
In the same way, without further comment, I will create a CA for users, which will be highlighted by OU: Users.
Key generation:
CSR creation:
Parameters:
Country Name (2 letter code) [AU]:PL
State or Province Name (full name) [Some-State]:kuj-pom
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MyCompany
Organizational Unit Name (eg, section) []:Users
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:
Signature by Root CA:
Ok, we also have the Sandbox Server CSR that needs to be signed by the Intermediate CA. This can now be done:
I postponed our SAPCryptolib PSE configuration process to build the CA structure. Now, the server certificate is signed, I can import it into my system. First, I'll concatenate the root CA certificate, intermediate certificate, and my server certificate into a file called sap_sandbox.chain.txt.
The next step is to import the certificate chain into the PSE in STRUST transaction:
The chain created in the txt file can be easily pasted into the window:
As a result, I see that the server certificate is no longer self-signed, but the entire certification chain is visible:
Finally the PSE must be saved.
In this step, the sandbox server officially became part of the organization. It can present itself with a certificate trusted by the company's authorization centers. However, you should be aware that it doesn't do this yet, because SNC is disabled in the system settings. In a while, though, this will be changed.
I'm not a fan of enabling SNC with this wizard, but it's fine for the first time. Next time, you'll probably configure the steps manually with full control. But for now, let's use the SNCWIZARD transaction.
Apart from setting up the certificates, which has already been done, this is the most important part of the wizard.
The most important parameters are listed below.
Enable SNC, the foundation for everything else:
snc/enable = 1
Set server SNC string, which is its identity:
snc/identity/as = p:CN=sandbox.mydomain.internal, OU=IT, O=MyCompany, C=PL
Still accept unencrypted communication at various levels:
snc/accept_insecure_cpic = 1
snc/accept_insecure_gui = 1
snc/accept_insecure_rfc = 1
snc/permit_insecure_start = 1
Set path to library for authentication, which is by default SAP CommonCryptoLib:
snc/gssapi_lib = $(SAPCRYPTOLIB)
After changing the profile parameters, a restart is required, which is visible in the next step of the wizard:
The next step has already been taken. However, I can take this opportunity to add Intermediate Users CA to the trusted list. This may not be necessary because the server trusts the Root CA, which should be sufficient. But this shows how to do it for other authorities.
The wizard opens STRUST transaction. Let's open the SNC SAPCryptolib section, switch to edit mode, import the certificate in the lower part of the window and add it to the trust list.
This should add our Intermediate Users CA (OU=Users) to the SNC SAPCryptolib trusted list. The PSE should be saved after this operation.
The wizard is now complete.
Now I can check if the encryption is working. To do this, I need to enable SNC in the system definition in my SAP GUI. The second tab contains the required settings.
But what happened? After trying to connect, I see an error: Peer certificate path not trusted.
Let's remember that trust is a two-way street. The client tries to connect to the server, the server presents its certificate, but the client doesn't know if the certificate is trusted. If the destination is really the server that is expected.
I need to trust the server certificate directly or its certificate issuers. Let's add the root certificate to the Windows repository. I need to use Manage User Certificates (certmgr) option in my Windows 11. From Trusted Root Certification Authorities I choose All Tasks / Import and select my Root CA certificate - ca.cert.pem.
The Root CA, distinguished by OU=Security should appear on the list.
Now, when I try to log in, I get a warning:
No user exists with SNC name "p:SNC ENCRYPTION ONLY (X.509 SERVER AUTH)"
But I can log in with username and password. I can also confirm that the connection is encrypted. This is the first success. SNC is enabled, the connection is secure.
As I have already demonstrated, the client trusts the server. What can be done so that the server also trusts the client and allows logging in based on the certificate? First of all, I must have the certificate! I need to return to my Linux-based CA and run some openssl commands.
Key generation is the basis of a certificate. You already know this part:
I don't want a self-signed certificate, so I need to generate a CSR:
Parameters are required as always:
Country Name (2 letter code) [AU]:PL
State or Province Name (full name) [Some-State]:kuj-pom
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MyCompany
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:TESTUSER
Email Address []:
So far it's the same as always, but now I need to have it signed by Intermediate Users CA, but as a client certificate. This requires a small additional configuration file. Let's save it as intermediateUsersCA/client.cnf:
Then I can sign it with Intermediate CA key and certificate:
The command uses several files - user certificate CSR, CA certificate, CA key, and the small config file. As a result, it produces a signed certificate named testuser.crt.pem.
But to be honest, it is not common practice to deliver unprotected certificate and key to the user. It's much better to put everything in a password-protected p12 container. Such a file consists of private key and trust list. Yes, this is similar to SAP PSE, but closer to SSL world.
The command combines user private key, user certificate, intermediate CA certificate and root CA certificate in one file named testuser.p12. Export password protects the container.
The p12 file generated in the previous step can be imported into the user's personal keystore using certmgr. It's a similar operation to the root certificate import that was done earlier.
It's worth mentioning that one of the import options allows exports from the keystore. This isn't the best idea because the key should be protected in the keystore. That's the reason why in many companies the certificates are delivered on a physical smart card, where it is not possible to extract the private keys.
Successful import activates the test user certificate, which can be checked in the Certificates tab.
Client is almost ready to use SAP Single Sign-On in SAP GUI. There are two missing parts - connection between SAP GUI and user certificate and user account configuration.
The first problem is easily solved by installing the SAP Secure Login Client 3.0, which is part of the SAP Single Sign-On 3.0 solution and can be downloaded from the SAP Portal.
When the tool is installed, you can select a previously imported certificate for SSO.
Of course, the system needs to know how to map the client to the existing user account. This mapping is defined in transaction SU01. The SNC tab contains the required options. The most important one is SNC name, where you need to enter the value copied from SAP Secure Login Client by selecting the Copy SNC name to clipboard option. The SNC string starts with p:.
You can decide if password logon is still enabled or if SSO is the only option for the user.
Finally, the user should be able to access the system without a password.
I hope this post was interesting or at least useful. Yes, it is quite long, while I wanted to show as comprehensive and logical as possible process of configuring certificate-based encryption and SSO. It could not be done without the lengthy CA-related part, which is usually beyond the responsibility of Basis administrators. However, even when you are not responsible for something, it is good to know how it works.
There seems to be no doubt that encryption is a must. On the other hand, I hope that this post will perhaps inspire someone to build a professional CA as well. Keep in mind, however, that this post can at best inspire, as it does not address many challenges in this area.
SAP supports the Secure Network Communication Protocol (SNC), which is based on SSL. However, it must be explicitly configured to enable secure communication between the SAP GUI and the SAP server. I will try to explain how to do this. The first step is to prepare certificates on the SAP side. For this I need a Certification Authority (CA), which has to be built from scratch in a very simplified version. This will make it possible to encrypt the communication between the client and the server. Then I will look at the possibility of authenticating the client with a certificate, which will provide SSO functionality.
There is no denying that this is a very broad topic, so expect some simplifications, especially in the CA build area. Certain topics and detailed descriptions are simply beyond the scope of the blog post. But it is also a fully functional end-to-end setup with all the necessary configuration elements.
Preparations
I have prepared a completely fresh setup to ensure that all steps and configurations are included in this text. I used the ABAP Platform Trial, which provides a docker image with S/4HANA 1909, which is more than enough for this exercise. In fact, I have experience with the same configuration on many older and newer versions of SAP Netweaver/ABAP Platform, and I see no major differences in this part of the system.
I also installed a fresh SAP GUI 8.0 with two options selected:
- SAP GUI for Windows
- SNC Client Encryption 2.0
Later I will install an additional component, but this is not required to enable SNC, so we'll do it in the SSO-related part.
PSE creation
What is PSE? It is a kind of a local repository that can store a private key and trusted certificates. It is used in various scenarios involving secure communication protocols such as SSL. PSE management is essential for the security of SAP systems. There are several default PSEs used by SAP system for various purposes. SNC SAPCryptolib PSE is valid for SSO.
Let's create the PSE in edit mode of STRUST transaction.
PSE creation in STRUST
There are some details I need to fill in. The first part is related to your organization and the future subject of the certificate. The second part is more security related. It's not the place to discuss details, but today a 4096-bit RSA key seems to be a good choice.
PSE details
As a result, I get the PSE, which contains a private key and a self-signed certificate.
A newly generated PSE
Of course, I like to show real life scenario, so self-signed certificate is not what is expected. I need to prepare a Certificate Signing Request that can be sent to my professional CA to establish trust in my organization. Let's generate the CSR.
CSR generation
Then the system asks for the signature algorithm, but the PSE algorithm is fine. I don't want any alternative names either, so I just accept the defaults. The result is a certificate request that can be saved to a file or copied to a text file.
Certificate request
I can check how the PSE is visible at the operating system level. This is a file that can be maintained with the sapgenpse command. I can get the main certificate details, including a subject, issuer, and expiration date. The subject is the same as the issuer, so this is a self-signed certificate.
SAPSNCS.pse
Certification Authority
Now I need to focus on the non-SAP part of the exercise. The CSR is already in place, so the CA needs to do the signing. But I don't have a CA yet, so I need to build one.
Please note that even though I try to build the correct structure of the CA, there are simplifications in the setup. I build the CA for our exercise purposes only, without following all the security rules related to CA separation, full key management, CRL process, etc.
Let's start with the structure. We need a Root CA, which will be trusted in our organization. The root CA certificate is always self-signed and trust is established by explicitly adding the authority to the trusted list. This can be done by the administrator or by the system/software vendor. In this case, the administrator is responsible.
Then I will create two intermediate CAs: one for servers and one for users. Finally, I'll sign the sandbox server certificate with the first CA. The second CA will generate and sign a client certificate for a test user.
CA structure
Once the layout is known, then the creation process can be started from the root CA. The directory structure below can help you keep things organized.
mkdir CA
mkdir CA/rootCA/
mkdir CA/intermediateServersCA/
mkdir CA/intermediateUsersCA/Root CA
Root CA is like any other certificate, so a private key is required.
sandbox:~$ openssl genrsa -out CA/rootCA/ca.key.pem 4096The command created a file with the key. Remember, this is the most secret file in your entire CA infrastructure. It must be kept private. Let's create a self-signed certificate based on the key.
openssl req -x509 -sha256 -new -nodes -key CA/rootCA/ca.key.pem -days 3650 -out CA/rootCA/ca.cert.pemSome option must be provided to build the subject of the certificate:
Country Name (2 letter code) [AU]:PL
State or Province Name (full name) [Some-State]:kuj-pom
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MyCompany
Organizational Unit Name (eg, section) []:Security
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:
In real life, you'll probably add a human-readable common name, but this is not mandatory. We'll differentiate the root CA by organizational unit, which is Security.
Now I have two files - one with private key, which is secret. The second one is certificate, so public part of the pair. As I mentioned earlier, the root CA is always self-signed, so there is no need to generate a CSR. Therefore, the root CA is ready. Simple, right?
Intermediate CA for Servers
As always, my first step is the creation of a private key:
openssl genrsa -out intermediateServersCA/interServers.key.pem 4096The key has been generated. Here procedure differs from the Root CA, so I need to generate signing request:
openssl req -key intermediateServersCA/interServers.key.pem -new -sha256 -out intermediateServersCA/interServers.csr.pemI need to provide input. Please note, that this CA is distinguished by OU: Servers.
Country Name (2 letter code) [AU]:PL
State or Province Name (full name) [Some-State]:kuj-pom
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MyCompany
Organizational Unit Name (eg, section) []:Servers
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:
The interServers.csr.pem CSR file is located in the intermediateServersCA directory. It needs to be signed by our Root CA. We have everything on one server, so only one command is required:
openssl x509 -req -in intermediateServersCA/interServers.csr.pem -days 3650 -CA rootCA/ca.cert.pem -CAkey rootCA/ca.key.pem -CAcreateserial -out intermediateServersCA/interServers.cert.pemAs you probably noticed, in addition to the CSR, the root CA key and certificate were also required to complete the process. The most important thing is that I now have a signed certificate for the intermediate CA. This CA will be used to sign leaf server certificates.
You can verify that the new CA (OU=Servers) is signed by the root CA (OU=Security):
Intermediate CA for Users
In the same way, without further comment, I will create a CA for users, which will be highlighted by OU: Users.
Key generation:
openssl genrsa -out intermediateUsersCA/interUsers.key.pem 4096CSR creation:
openssl req -key intermediateUsersCA/interUsers.key.pem -new -sha256 -out intermediateUsersCA/interUsers.csr.pem
Parameters:
Country Name (2 letter code) [AU]:PL
State or Province Name (full name) [Some-State]:kuj-pom
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MyCompany
Organizational Unit Name (eg, section) []:Users
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:
Signature by Root CA:
openssl x509 -req -in intermediateServersCA/interServers.csr.pem -days 3650 -CA rootCA/ca.cert.pem -CAkey rootCA/ca.key.pem -CAcreateserial -out intermediateServersCA/interServers.cert.pemSigning SAP server certificate
Ok, we also have the Sandbox Server CSR that needs to be signed by the Intermediate CA. This can now be done:
openssl x509 -req -in intermediateServersCA/csr/sap_sandbox_csr.pem -days 365 -CA intermediateServersCA/interServers.cert.pem -CAkey intermediateServersCA/interServers.key.pem -CAcreateserial -out intermediateServersCA/csr/sap_sandbox.cert.pemImporting CSR to SAP PSE
I postponed our SAPCryptolib PSE configuration process to build the CA structure. Now, the server certificate is signed, I can import it into my system. First, I'll concatenate the root CA certificate, intermediate certificate, and my server certificate into a file called sap_sandbox.chain.txt.
Certificate chain preparation
The next step is to import the certificate chain into the PSE in STRUST transaction:
The chain created in the txt file can be easily pasted into the window:
As a result, I see that the server certificate is no longer self-signed, but the entire certification chain is visible:
Finally the PSE must be saved.
In this step, the sandbox server officially became part of the organization. It can present itself with a certificate trusted by the company's authorization centers. However, you should be aware that it doesn't do this yet, because SNC is disabled in the system settings. In a while, though, this will be changed.
SAP Single Sign-On Wizard
I'm not a fan of enabling SNC with this wizard, but it's fine for the first time. Next time, you'll probably configure the steps manually with full control. But for now, let's use the SNCWIZARD transaction.
Apart from setting up the certificates, which has already been done, this is the most important part of the wizard.
The most important parameters are listed below.
Enable SNC, the foundation for everything else:
snc/enable = 1
Set server SNC string, which is its identity:
snc/identity/as = p:CN=sandbox.mydomain.internal, OU=IT, O=MyCompany, C=PL
Still accept unencrypted communication at various levels:
snc/accept_insecure_cpic = 1
snc/accept_insecure_gui = 1
snc/accept_insecure_rfc = 1
snc/permit_insecure_start = 1
Set path to library for authentication, which is by default SAP CommonCryptoLib:
snc/gssapi_lib = $(SAPCRYPTOLIB)
After changing the profile parameters, a restart is required, which is visible in the next step of the wizard:
The next step has already been taken. However, I can take this opportunity to add Intermediate Users CA to the trusted list. This may not be necessary because the server trusts the Root CA, which should be sufficient. But this shows how to do it for other authorities.
The wizard opens STRUST transaction. Let's open the SNC SAPCryptolib section, switch to edit mode, import the certificate in the lower part of the window and add it to the trust list.
This should add our Intermediate Users CA (OU=Users) to the SNC SAPCryptolib trusted list. The PSE should be saved after this operation.
The wizard is now complete.
Client configuration and test
Now I can check if the encryption is working. To do this, I need to enable SNC in the system definition in my SAP GUI. The second tab contains the required settings.
SNC in SAP GUI settings
But what happened? After trying to connect, I see an error: Peer certificate path not trusted.
Let's remember that trust is a two-way street. The client tries to connect to the server, the server presents its certificate, but the client doesn't know if the certificate is trusted. If the destination is really the server that is expected.
I need to trust the server certificate directly or its certificate issuers. Let's add the root certificate to the Windows repository. I need to use Manage User Certificates (certmgr) option in my Windows 11. From Trusted Root Certification Authorities I choose All Tasks / Import and select my Root CA certificate - ca.cert.pem.
Manage User Certificates
The Root CA, distinguished by OU=Security should appear on the list.
Now, when I try to log in, I get a warning:
No user exists with SNC name "p:SNC ENCRYPTION ONLY (X.509 SERVER AUTH)"
But I can log in with username and password. I can also confirm that the connection is encrypted. This is the first success. SNC is enabled, the connection is secure.
Client certificate generation
As I have already demonstrated, the client trusts the server. What can be done so that the server also trusts the client and allows logging in based on the certificate? First of all, I must have the certificate! I need to return to my Linux-based CA and run some openssl commands.
Key generation is the basis of a certificate. You already know this part:
openssl genrsa -out intermediateUsersCA/testuser.key.pem 4096I don't want a self-signed certificate, so I need to generate a CSR:
openssl req -key intermediateUsersCA/testuser.key.pem -new -sha256 -out intermediateUsersCA/testuser.csr.pemParameters are required as always:
Country Name (2 letter code) [AU]:PL
State or Province Name (full name) [Some-State]:kuj-pom
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MyCompany
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:TESTUSER
Email Address []:
So far it's the same as always, but now I need to have it signed by Intermediate Users CA, but as a client certificate. This requires a small additional configuration file. Let's save it as intermediateUsersCA/client.cnf:
nsCertType = client
extendedKeyUsage = clientAuthThen I can sign it with Intermediate CA key and certificate:
openssl x509 -req -days 365 -in intermediateUsersCA/testuser.csr.pem -sha256 -CA intermediateUsersCA/interUsers.cert.pem -CAkey intermediateUsersCA/interUsers.key.pem -CAcreateserial -out intermediateUsersCA/testuser.crt.pem -extfile intermediateUsersCA/client.cnfThe command uses several files - user certificate CSR, CA certificate, CA key, and the small config file. As a result, it produces a signed certificate named testuser.crt.pem.
But to be honest, it is not common practice to deliver unprotected certificate and key to the user. It's much better to put everything in a password-protected p12 container. Such a file consists of private key and trust list. Yes, this is similar to SAP PSE, but closer to SSL world.
openssl pkcs12 -export -inkey intermediateUsersCA/testuser.key.pem -in intermediateUsersCA/testuser.crt.pem -certfile rootCA/ca.cert.pem -certfile intermediateUsersCA/interUsers.cert.pem -out testuser.p12The command combines user private key, user certificate, intermediate CA certificate and root CA certificate in one file named testuser.p12. Export password protects the container.
Importing user certificate
The p12 file generated in the previous step can be imported into the user's personal keystore using certmgr. It's a similar operation to the root certificate import that was done earlier.
Personal certificate import
It's worth mentioning that one of the import options allows exports from the keystore. This isn't the best idea because the key should be protected in the keystore. That's the reason why in many companies the certificates are delivered on a physical smart card, where it is not possible to extract the private keys.
Successful import activates the test user certificate, which can be checked in the Certificates tab.
Correctly imported certificate
Single Sign-On
Client is almost ready to use SAP Single Sign-On in SAP GUI. There are two missing parts - connection between SAP GUI and user certificate and user account configuration.
The first problem is easily solved by installing the SAP Secure Login Client 3.0, which is part of the SAP Single Sign-On 3.0 solution and can be downloaded from the SAP Portal.
SAP Secure Login Client installation
When the tool is installed, you can select a previously imported certificate for SSO.
Certificate/key selection for SSO
Of course, the system needs to know how to map the client to the existing user account. This mapping is defined in transaction SU01. The SNC tab contains the required options. The most important one is SNC name, where you need to enter the value copied from SAP Secure Login Client by selecting the Copy SNC name to clipboard option. The SNC string starts with p:.
SNC configuration in user account
You can decide if password logon is still enabled or if SSO is the only option for the user.
Finally, the user should be able to access the system without a password.
Success, certificate-based SSO is possible!
Conclusion
I hope this post was interesting or at least useful. Yes, it is quite long, while I wanted to show as comprehensive and logical as possible process of configuring certificate-based encryption and SSO. It could not be done without the lengthy CA-related part, which is usually beyond the responsibility of Basis administrators. However, even when you are not responsible for something, it is good to know how it works.
There seems to be no doubt that encryption is a must. On the other hand, I hope that this post will perhaps inspire someone to build a professional CA as well. Keep in mind, however, that this post can at best inspire, as it does not address many challenges in this area.
- SAP Managed Tags:
4 Comments
