In his very useful blog in 2016, SAP Expert Cristiano Hansen writes about how to create a CSR and import a public certificate response.
Unfortunately, as hackers become more intrusive, SAP has been forced to respond. As business demands move towards tighter security as well as enterprise-wide Robotics Process Automation (RPA), having trusted certificates becomes a basic building block to greater productivity. This blog post provides updated process details for newer versions of SAP (Basis 75x) and also offers more information on how to select the right algorithms, SAN (Subject Alternative Name, etc.). The steps to set up trusted certificates in an SAP ABAP system are shown below.
Note: server and entity names in the screenshots do not reference any real firm or entity and are shown for demo purposes only.
Step 1. Go to transaction STRUST and check the PSE under SAP Server Standard:
The CN (Common Name) above does not reflect the desired FQDN of the server so we have to modify it. To do so, switch to Change mode, right-click on “SSL Server Standard” and click on “Replace”:
Select “Yes” if prompted:
In this example, our selected SID is KQ3 and we have two application servers so we can use a generic entry for the SAP system as a whole. In this case, we have chosen KQ3 as the generic name.
Step 2. Make sure that it is at least RSA/2048/SHA256:
Set them to use their public/reverse proxy hostnames: SAPECCCIQ01.<<external-name>>.com and SAPECCDIQ01.<<external-name>>.com. Note that his may need to be obtained from the team that creates the external certificates if segregation of duties rules are applied.
Sometimes, you may just be given the Distinguished Name (DN) string. In such a case, just click the Change (pencil) button in the graphic above and enter the whole thing in one string:
If DN string is:
“CN=sapsev70.megacorp.com, OU=Mega Corporation, O=Mega Corporation, L=Anytown, C=US”
then you may enter as below:
Press Enter and you will get the following:
Step 3. Save and exit STRUST and come back to the same transaction
Step 4. Double-click on the new PSE and select “Create Certificate Request”
For attributes, you MUST select SHA256 as of this writing:
Step 5. Create additional Subject Alternative Names (SAN) for the internal and external FQDN. Note that due to recent rules that have tightened security, it is NOT possible to have internal FQDNs validated by external signing authorities like Verisign. Hence, it is no longer possible to have both internal and external FQDNs in one certificate.
Also, to address new requirements on the Chrome/Edge browser and some variants, the Subject Alternative Name or SAN (also known as Alternative Owner Name) must be defined:
You will get the Certificate Request as an output. Save it and send to your CA to be externally signed. (Several large companies are permitted to sign certificates internally and/or externally. In our case, we want external certificates). The difference between internal and external certificates is outside the scope of this blog.
Step 6. Send to your certifying team and request and externally-signed certificate, with all root/intermediate certificates.
Let’s Encrypt is a service that can now provide free externally-signed certificates. Although the “free” service is restricted it is a useful option. You can check out how to use that service by reviewing Zoltan Sekeres’s very useful blog.
You will receive a zip file where the following two are key:
Open the files in Notepad++ or any other similar editor, merge the contents as below and save. In this case, we chosen an arbitrary name “SignedCertificateResponse—KQ3.crt”:
Step 7. Now import the merged file in STRUST/Import Certificate Response as shown below:
Step 8. Import the file “SignedCertificateResponse—KQ3.crt”:
At this point, click on Server PSE and Save As:
Be sure to select the right option below for SSL Server! Easy to Miss!
Step 9. The test on the base browser connection should now work WITHOUT any prompts or errors. (The example below merely shows that the certificate connection has been made. Enabling the service itself is a separate process):
Still have Issues? Check out the Troubleshooting steps below.
Troubleshooting:
If you have trouble loading the PSE, delete it instead of doing a Replace in Step 1 above:
Also, delete Temporary Files:
Ensure that the SMICM service defined is for the right port. In our case, it is the default 443:
Ensure that the ICM is restarted implicitly by STRUST. (You will get a message PSE Saved/ICM was Notified, which means that it was internally activated):
Conclusion. You have now successfully imported your externally-signed certificate! If you have problems, please review the steps above, check out the trouble-shooting steps or contact the author.
Unfortunately, as hackers become more intrusive, SAP has been forced to respond. As business demands move towards tighter security as well as enterprise-wide Robotics Process Automation (RPA), having trusted certificates becomes a basic building block to greater productivity. This blog post provides updated process details for newer versions of SAP (Basis 75x) and also offers more information on how to select the right algorithms, SAN (Subject Alternative Name, etc.). The steps to set up trusted certificates in an SAP ABAP system are shown below.
Note: server and entity names in the screenshots do not reference any real firm or entity and are shown for demo purposes only.
Step 1. Go to transaction STRUST and check the PSE under SAP Server Standard:
The CN (Common Name) above does not reflect the desired FQDN of the server so we have to modify it. To do so, switch to Change mode, right-click on “SSL Server Standard” and click on “Replace”:
Select “Yes” if prompted:
In this example, our selected SID is KQ3 and we have two application servers so we can use a generic entry for the SAP system as a whole. In this case, we have chosen KQ3 as the generic name.
Step 2. Make sure that it is at least RSA/2048/SHA256:
Set them to use their public/reverse proxy hostnames: SAPECCCIQ01.<<external-name>>.com and SAPECCDIQ01.<<external-name>>.com. Note that his may need to be obtained from the team that creates the external certificates if segregation of duties rules are applied.
Sometimes, you may just be given the Distinguished Name (DN) string. In such a case, just click the Change (pencil) button in the graphic above and enter the whole thing in one string:
If DN string is:
“CN=sapsev70.megacorp.com, OU=Mega Corporation, O=Mega Corporation, L=Anytown, C=US”
then you may enter as below:
Press Enter and you will get the following:
Step 3. Save and exit STRUST and come back to the same transaction
Step 4. Double-click on the new PSE and select “Create Certificate Request”
For attributes, you MUST select SHA256 as of this writing:
Step 5. Create additional Subject Alternative Names (SAN) for the internal and external FQDN. Note that due to recent rules that have tightened security, it is NOT possible to have internal FQDNs validated by external signing authorities like Verisign. Hence, it is no longer possible to have both internal and external FQDNs in one certificate.
Also, to address new requirements on the Chrome/Edge browser and some variants, the Subject Alternative Name or SAN (also known as Alternative Owner Name) must be defined:
You will get the Certificate Request as an output. Save it and send to your CA to be externally signed. (Several large companies are permitted to sign certificates internally and/or externally. In our case, we want external certificates). The difference between internal and external certificates is outside the scope of this blog.
Step 6. Send to your certifying team and request and externally-signed certificate, with all root/intermediate certificates.
Let’s Encrypt is a service that can now provide free externally-signed certificates. Although the “free” service is restricted it is a useful option. You can check out how to use that service by reviewing Zoltan Sekeres’s very useful blog.
You will receive a zip file where the following two are key:
- A file named Nnnnnnnnnnn.crt <<this is the signed certificate>>
- A file named gd_bundle-g2-g1.crt <<this contains all the root and intermediate certificates as sent by GoDaddy, which is one example of a trust certificate provider>>
Open the files in Notepad++ or any other similar editor, merge the contents as below and save. In this case, we chosen an arbitrary name “SignedCertificateResponse—KQ3.crt”:
Chain of Root/intermediate Certificates
Server Certificate
Step 7. Now import the merged file in STRUST/Import Certificate Response as shown below:
Step 8. Import the file “SignedCertificateResponse—KQ3.crt”:
At this point, click on Server PSE and Save As:
Be sure to select the right option below for SSL Server! Easy to Miss!
Step 9. The test on the base browser connection should now work WITHOUT any prompts or errors. (The example below merely shows that the certificate connection has been made. Enabling the service itself is a separate process):
Still have Issues? Check out the Troubleshooting steps below.
Troubleshooting:
If you have trouble loading the PSE, delete it instead of doing a Replace in Step 1 above:
Also, delete Temporary Files:
Ensure that the SMICM service defined is for the right port. In our case, it is the default 443:
Ensure that the ICM is restarted implicitly by STRUST. (You will get a message PSE Saved/ICM was Notified, which means that it was internally activated):
Conclusion. You have now successfully imported your externally-signed certificate! If you have problems, please review the steps above, check out the trouble-shooting steps or contact the author.
- SAP Managed Tags:
