Secure Socket Layer (SSL) is one of the important topics to address when coming on to access of systems over browser. When we say that a particular site is SSL enabled, it means , we have issued certificates for that specific system Uniform Resource Locator (URL) which includes the Fully Qualified Domain Name (FQDN). The certificate issued can either be self signed or signed by an Internal PKI or from a known third party PKI (Public Key Infrastructure)
The certificates are consumed by the different browsers and they issue communication to the endusers on whether the certificates issued are trusted or not by that particular browser
The browsers which are widely used are Google Chrome, Microsoft Internet Explorer, Mozilla Firefox and Safari.
This blog will discuss about the way Google Chrome consumes the issued certificates to trust or not to trust the website that is been accessed
The primary prerequisite for any browser is that ROOT issuer certificate, issuing the certificate for our website need to be added and maintained in the ROOT CA list of the browser certificate store.
As next step, the browser will interpret the details within the issued server certificate to check if they are valid of not.
The certificates issued to web sites have some specific attributes which will be used to identify the websites
Typically the CN part of the certificate is used to identify the server.
In Google Chrome , the identification of the website using issued server certificates is based on the dnsnames been maintained on the Subject Alternative Name Attribute. If in case we have multiple dnsnames for the same site, we need to maintain all of them in as part of the certificate. If we fail to do this, then the specific website will be displayed as having invalid certificate when accessed from google chrome browser.
To summarize and to understand, if we maintain the CN value only with the FQDN without maintaining the DNS name value, the certificate will be marked invalid in chrome though it will be accepted by most of the other browsers
Now the next question, is how do we generate the Certificate Signing Request (CSR) to accommodate these requirements in the request
In the case of the SAP ABAP system, we use STRUST transaction to generate as well as to manage the certificates for different certificate stores.
Step1 : Execute Tcode STRUST
Step 2: Select the Specific Certificate store. For SSL certificates, select SSL Server standard
Step 3: Click Create Certificate Request
Step 4: In the Pop-up screen , Attributes for Certificate requests, Click Append row and provide all the alternate names (dns Names) for the server one by one
Step 5: Click on Continue to generate the CSR
Step 6: Get the CSR signed by a PKI
Step 7: Import the signed request into the system by selecting “Import certificate response” for SSL Server standard
In the case of the SAP JAVA system, it is not straight forward and intuitive from the NWA UI.
There is a very good blog https://blogs.sap.com/2015/10/26/subject-alternative-name-san-with-sapgenpse-commoncryptolib/ which explains the use of SAPGENPSE command to generate the Certificate Signing requests. This process can be followed for both SAP ABAP and JAVA systems from the Operating System level.
If we use the SAP Single Sign-On solution, then we can directly issue the SSL Certificates for the servers from the Secure Login server Component with the required DNS names and then export it to a p12 format certificate. The exported certificate can then be imported into the SAP JAVA system or ABAP system
With the various options discussed above, we can generate the SSL server certificates as well as Certificate Signing Requests for both ABAP and JAVA systems with the dnsnames been maintained in the certificate. If we go by these procedures we can make sure that Chrome is able to trust the issued certificates for the servers and is compliant across all the browsers
The certificates are consumed by the different browsers and they issue communication to the endusers on whether the certificates issued are trusted or not by that particular browser
The browsers which are widely used are Google Chrome, Microsoft Internet Explorer, Mozilla Firefox and Safari.
This blog will discuss about the way Google Chrome consumes the issued certificates to trust or not to trust the website that is been accessed
The primary prerequisite for any browser is that ROOT issuer certificate, issuing the certificate for our website need to be added and maintained in the ROOT CA list of the browser certificate store.
As next step, the browser will interpret the details within the issued server certificate to check if they are valid of not.
The certificates issued to web sites have some specific attributes which will be used to identify the websites
Typically the CN part of the certificate is used to identify the server.
In Google Chrome , the identification of the website using issued server certificates is based on the dnsnames been maintained on the Subject Alternative Name Attribute. If in case we have multiple dnsnames for the same site, we need to maintain all of them in as part of the certificate. If we fail to do this, then the specific website will be displayed as having invalid certificate when accessed from google chrome browser.
To summarize and to understand, if we maintain the CN value only with the FQDN without maintaining the DNS name value, the certificate will be marked invalid in chrome though it will be accepted by most of the other browsers
Now the next question, is how do we generate the Certificate Signing Request (CSR) to accommodate these requirements in the request
In the case of the SAP ABAP system, we use STRUST transaction to generate as well as to manage the certificates for different certificate stores.
Step1 : Execute Tcode STRUST
Step 2: Select the Specific Certificate store. For SSL certificates, select SSL Server standard
Step 3: Click Create Certificate Request
Step 4: In the Pop-up screen , Attributes for Certificate requests, Click Append row and provide all the alternate names (dns Names) for the server one by one
Step 5: Click on Continue to generate the CSR
Step 6: Get the CSR signed by a PKI
Step 7: Import the signed request into the system by selecting “Import certificate response” for SSL Server standard
In the case of the SAP JAVA system, it is not straight forward and intuitive from the NWA UI.
There is a very good blog https://blogs.sap.com/2015/10/26/subject-alternative-name-san-with-sapgenpse-commoncryptolib/ which explains the use of SAPGENPSE command to generate the Certificate Signing requests. This process can be followed for both SAP ABAP and JAVA systems from the Operating System level.
If we use the SAP Single Sign-On solution, then we can directly issue the SSL Certificates for the servers from the Secure Login server Component with the required DNS names and then export it to a p12 format certificate. The exported certificate can then be imported into the SAP JAVA system or ABAP system
With the various options discussed above, we can generate the SSL server certificates as well as Certificate Signing Requests for both ABAP and JAVA systems with the dnsnames been maintained in the certificate. If we go by these procedures we can make sure that Chrome is able to trust the issued certificates for the servers and is compliant across all the browsers
- SAP Managed Tags:
2 Comments
