In some scenarios, it may be interesting to use a wildcard certificate to match different instances. First of all, it’s important to understand how they work. Everything is perfectly explained in RFC 6125.
Creating the PSE
First of all, it’s necessary to create the ‘SSL Server Standard’, which is responsible for all incoming connections that the server may receive.
A new window will appear, where you can define the ‘Name’ to be a wildcard value.
Hit the confirm button and you will notice a green entry for each instance that you have in your system.
By selecting the ‘SSL server Standard’, the wildcard certificate will appear:
Also, you can check that each instance has a specific certificate create to it. In my system, there is only one instance, and the certificate can be checked by double-clicking the instance specific button.
Testing the scenario
Now, we can test the communication. Let’s use the ‘WEBGUI’ transaction to check whether the communication is secure or not.
Not working. This is a common error and the solution is described in KBA 2339387. Basically, the web browser doesn’t trust in my server’s certificate, because it is self-signed and I did not imported it in the browser.
Signing the wildcard certificate
To solve this issue, let’s sign the wildcard certificate. If you have any queries about it, you can check this blog post, which contains a guide explaining how to generate the Request and import the Response received by the Certificate Authority.
Ok. Certificate signed:
Let’s test the WebGUI again.
Wait, what? The same error happened. Let’s take a closer look at this error.
If you click on ‘Continue to this website (not recommended)’ message, the login page of WebGUI will appear. Then, we can click in ‘Certificate error’ (at the right end of the red address bar) to show up the certificate returned by the server.
Well, this is not our wildcard certificate, but the instance specific.
Actually, this is the expected behavior. The Application Server will always return the instance specific certificate.
What we need to do now is to configure the Application Server to use the wildcard certificate instead of the instance specific.
Changing the certificate for one instance
This is simple. Access ‘STRUST’ transaction and:
- Right click the ‘SSL server Standard’;
- Select the ‘Change’ option.
A new window will appear, showing the DN of each instance.
Then, you can delete the value of the instance specific field (left it empty), as the wizard states:
“Instances with empty distinguished names are given the standard PSE”.
In fact, the process can be simplified when the PSE was created. In the first creation wizard, it’s possible to already do this part of the configuration and do not create any instance specific entries, only the system wide one (which should be created with the wildcard certificate).
To finish, just confirm the changes. Back in STRUST, hit the ‘Save’ button at the top.
Depending on you NW release, it may be necessary to restart the ICM to the changes take effect.
Let’s check the WebGUI again:
Now, everything is working fine. There is no error message and the wildcard certificate is being used. 😀
Usually, there is more than one instance that will use this certificate. All you need to do is, in the ‘Change’ window, to configure the wildcard certificate to be used in that instance too.
510007 : Setting up SSL on Application Server ABAP
2339387 : Warning “There is a problem with this website’s security certificate” when accessing AS ABAP via HTTPS URL
RFC 6125 : Best Practices for Checking of Server Identities in the Context of Transport Layer Security (TLS)
How to create the CSR and how to import the certificate response? : Signing certificates in STRUST
2445947 : [WEBINAR] Setting up SSL on NetWeaver Application Server for ABAP