Configuring HTTPS

Configuring HTTPS in SAP Basis

I. Introduction to HTTPS and SSL/TLS in SAP

HTTPS: Is simply HTTP over SSL/TLS. It provides encrypted communication and secure identification of a network web server.
SSL (Secure Sockets Layer) / TLS (Transport Layer Security): Cryptographic protocols that provide communication security over a computer network. TLS is the successor to SSL; when we talk about SSL today, we are usually referring to TLS.
Purpose in SAP:
- Secure communication for web-based SAP applications (e.g., Fiori Launchpad, Web Dynpro ABAP/Java, SAP GUI for HTML, Solution Manager).
- Secure communication between SAP systems (e.g., Web Dispatcher to backend, SOAP RFCs).
- Ensure data confidentiality, integrity, and server authentication.
Key Concepts:
- Certificates: Digital documents used to prove the ownership of a public key. They are issued by a Certificate Authority (CA) and contain the public key, domain name, issuer information, and validity period.
- Public Key Infrastructure (PKI): The framework to manage digital certificates.
- PSE (Personal Security Environment): SAP's container for cryptographic keys and certificates.
- CommonCryptoLib: SAP's default cryptographic library used for SSL/TLS and SNC.

II. Prerequisites for HTTPS Configuration

CommonCryptoLib: Ensure libsapcrypto.so (Linux) or sapcrypto.dll (Windows) is available in the kernel directory (DIR_EXE) on all relevant application servers. This is SAP's cryptographic library required for SSL/TLS.
License: No separate license required for CommonCryptoLib itself, but certain advanced features might require specific licenses (e.g., SAP NetWeaver SSO).
Ports: Ensure the HTTPS port (default 443, or $(SAPSYSTEMNAME)xx00 in SAP like 80$(SAPSYSTEMNAME) for HTTP and 443$(SAPSYSTEMNAME) for HTTPS, but often 5xx01 for ABAP, 5xx02 for Java) is open in firewalls between clients and SAP systems, and between SAP components.
Profile Parameters: Knowledge of relevant profile parameters in RZ10.
DNS Resolution: Ensure hostname is correctly resolvable (FQDN). The hostname in the certificate must match the FQDN used by clients.

III. HTTPS Configuration on SAP ABAP Stack

The primary tool for managing server certificates on the ABAP stack is STRUST (Trust Manager).

A. Steps to Configure HTTPS (Server Certificate):

Access STRUST: Log in to your SAP ABAP system and go to transaction STRUST.
Create/Select SSL Server Standard PSE:
- In the STRUST sidebar, navigate to the "SSL Server Standard" node (or create it if it doesn't exist). This PSE is typically used for general HTTPS communication.
- If a new PSE is required, right-click and choose "Create PSE". Provide a password and confirm.
Generate Certificate Request (CSR):
- Select the "SSL Server Standard" PSE. In the "PSE Status" section, you'll see details like Owner and Certificate Request.
- Click on "Create Certificate Request" (or "Regenerate Certificate Request").
- Fill in the distinguished name (DN) details (e.g., CN=<hostname.fqdn>, OU=<Org.Unit>, O=<Organization>, C=<Country>). Crucially, the Common Name (CN) MUST be the Fully Qualified Domain Name (FQDN) that clients will use to access the SAP system.
- Save the generated CSR file locally (e.g., server.csr).
Submit CSR to Certificate Authority (CA):
- Send the server.csr file to your trusted Certificate Authority (e.g., DigiCert, GoDaddy, internal PKI like Microsoft AD CS).
- The CA will issue a server certificate (often in .cer, .crt, or .pem format) and potentially a chain of root and intermediate certificates.
Import Certificate Response & CA Certificates:
- In STRUST, with the "SSL Server Standard" PSE selected, click on "Import Certificate Response". Select the server certificate file received from the CA. This imports your signed server certificate into the PSE.
- Import CA Certificates: This is very important. You need to import the entire certificate chain (Root CA, any Intermediate CAs) into the PSE's "Certificate List". For each CA certificate:
  - Click "Import Certificate" (yellow folder icon).
  - Choose the CA certificate file.
  - Click "Add to Certificate List" (green checkmark).
- Save: Click "Save" to persist the changes to the PSE.
Verify Configuration:
- Check STRUST to ensure your server certificate is valid and the CA chain is complete.
- Check SAP profile parameters (see section below).
- Restart ICM (Internet Communication Manager) via SMICM (Administration -> ICM -> Exit Soft -> Global). A full SAP system restart is usually not required unless profile parameters are changed.
Test HTTPS: Access the SAP system via a web browser using https://<hostname.fqdn>:<https_port>/sap/bc/gui/sap/its/webgui.

B. Key Profile Parameters (RZ10 / RZ11):

icm/server_port_0: Define the HTTPS port.
- Example: PROT=HTTPS, PORT=5xx01, TIMEOUT=600, PROCTIMEOUT=600 (where xx is instance number).
icm/hcm_proxy_port: If using a reverse proxy or Web Dispatcher, define this.
ssl/ssl_lib: Path to the CommonCryptoLib (e.g., $(DIR_EXE_ROOT)\sapjvm\jre\bin\sapjvm\sapjvm_6\lib\sapcrypto.dll or $(DIR_EXECUTABLE)/libsapcrypto.so).
ssl/ciphersuites: (Optional, but recommended) Restrict allowed cipher suites for stronger encryption. (e.g., 135:PFS:HIGH::EDH:SHA2).
ssl/client_ciphersuites: For client-side encryption when SAP is client.
icm/HTTPS/verify_client: Controls client certificate authentication (0=off, 1=optional, 2=required).
ssl/client_pse: Path to the PSE for outgoing HTTPS connections (e.g., for CALL_HTTP_CLIENT or SOAP messages from SAP). Defaults to SSL Client Standard in STRUST.
ssl/server_pse: Path to the PSE for incoming HTTPS connections. Defaults to SSL Server Standard in STRUST.
sec/libsapsecu: Path to the general security library (usually same as ssl/ssl_lib).

C. Client Certificate Authentication (Optional):

Purpose: Two-way authentication. Both client and server authenticate each other using certificates. Stronger security.
Setup:
1. Server-Side (STRUST):
  - Import the root CA certificate(s) that signed the client certificates into the SSL Server Standard PSE in STRUST.
  - Set icm/HTTPS/verify_client = 1 (optional) or 2 (required) in RZ10.
2. Client-Side:
  - User's browser/device must have a valid client certificate issued by a trusted CA.
  - Configure the client application to present the certificate.
3. User Mapping:
  - In SU01, for each user, go to "SNC" tab, then "Certificate" button. Import the user's client certificate and map it to the SAP user.

IV. HTTPS Configuration on SAP Java Stack (NetWeaver AS Java)

On the Java stack, certificate management is done via NWA (NetWeaver Administrator).

A. Steps to Configure HTTPS:

Access NWA: Log in to NWA (http://<host>:<port>/nwa).
Navigate to Key Storage: Configuration -> Security -> Certificates and Keys -> Key Storage.
Select Default View: This view holds the ICM_SSL_<SID> and ICM_SSL_PSEs.
Generate Key Pair and CSR:
- Select the Default view. Choose ICM_SSL_<SID> (or ICM_SSL_ for global server certificates).
- Click "Generate Key Pair and CSR Request".
- Fill in certificate request details (CN, OU, O, C). Again, CN MUST be the FQDN clients use.
- Download the CSR file.
Submit CSR to CA: Send the CSR to your CA and receive the server certificate and chain.
Import Certificate Response:
- In NWA Key Storage, select the ICM_SSL_<SID> entry.
- Click "Import Certificate Response". Select the server certificate received from CA.
Import CA Certificates:
- Import Root and Intermediate CA certificates into the TrustedCAs view in Key Storage.
- Click "Import Entry" -> "X.509 Certificate" for each CA certificate.
Configure HTTPS Port:
- Navigate to Configuration -> Infrastructure -> Java System Properties -> Services.
- Select com.sap.engine.services.ssl.manager.
- Check/set Port parameter (default 5xx02, where xx is instance number).
- Check UseHTTPS (must be true).
Restart: Restart the com.sap.engine.services.ssl.manager service, or the entire Java instance for full effect.
Test HTTPS: Access the Java system via https://<hostname.fqdn>:<https_port>/nwa.

B. Key Considerations for Java Stack:

Key Storage Views: Understanding different views (Default, TrustedCAs, TicketKeystore, etc.). TrustedCAs stores trusted root and intermediate CAs.
SSL Port: Java typically uses 5xx02 as the default HTTPS port.
Restart Requirement: Changing certificates often requires restarting the SSL service or the entire instance.

V. SAP Web Dispatcher HTTPS Configuration

The SAP Web Dispatcher acts as a reverse proxy for SAP systems. It's often the first point of contact for external HTTPS traffic.

Install CommonCryptoLib: Ensure libsapcrypto.so/sapcrypto.dll is installed.
Profile Parameters:
- icm/server_port_0: For incoming HTTPS (e.g., PROT=HTTPS, PORT=443, TIMEOUT=600).
- wdisp/ssl_encrypt = 1: Force Web Dispatcher to use HTTPS for communication with backend.
- wdisp/ssl_auth = 2: Use client certificate for authentication to backend (if configured).
- wdisp/ssl_handshake_timeout: Timeout for SSL handshake.
Certificate Management:
- Use sapgenpse command-line tool to manage Web Dispatcher's PSE.
- Steps similar to ABAP: Create PSE, generate CSR, get signed certificate, import response, import CA chain.
- The Web Dispatcher's certificate's CN should match the public FQDN that users access.
Backend Trust: The Web Dispatcher needs to trust the backend SAP systems' certificates if it's forwarding HTTPS to HTTPS. The backend system's CA certificates must be imported into the Web Dispatcher's SSL Client PSE or appropriate PSE for outgoing connections.
Backend HTTPS Configuration: Ensure backend ABAP/Java systems are also configured for HTTPS as outlined above.

VI. Important Configuration to Keep in Mind

FQDN (Fully Qualified Domain Name) Consistency:
- The Common Name (CN) in your server certificate MUST exactly match the FQDN that clients use to access your SAP system (e.g., myerp.mycompany.com).
- Mismatches will lead to browser security warnings (NET::ERR_CERT_COMMON_NAME_INVALID).
- Use Virtual Hostnames if behind a load balancer or Web Dispatcher.
Certificate Chain: Always import the entire certificate chain (Root CA, any Intermediate CAs) into the PSE's "Certificate List" (ABAP) or TrustedCAs view (Java). Browsers and clients need to validate the entire chain.
Expiration Dates: Certificates have validity periods. Implement a process to monitor certificate expiration (e.g., using STRUST or NWA alerts, or external tools) and renew them before they expire. An expired certificate immediately breaks HTTPS.
Strong Cipher Suites and TLS Versions:
- Profile Parameter ssl/ciphersuites: Explicitly define strong cipher suites (e.g., 135:PFS:HIGH::EDH:SHA2) to avoid weak encryption.
- Profile Parameter ssl/minimum_protocol_version: Set to TLS1.2 or higher (e.g., TLS1.3 if supported by your SAP/OS version) to disable older, less secure TLS versions (TLS 1.0, 1.1).
- Rationale: Protect against known vulnerabilities like POODLE, Heartbleed, etc.
Private Key Security: The private key associated with the PSE must be highly secure. Ensure file system permissions are strict (<sidadm> user only).
Trust Management (STRUST/NWA):
- For outgoing HTTPS connections (SAP as client), the client PSE needs to trust the CA that issued the target server's certificate.
- For incoming HTTPS connections (SAP as server), the server PSE needs to contain its own certificate and trust the CAs that issued any client certificates (if client authentication is used).
Port Allocation: Ensure the chosen HTTPS ports do not conflict with other services and are open in network firewalls.
Load Balancers/Reverse Proxies: If using a load balancer or Web Dispatcher, configure HTTPS at that layer first, and then decide if re-encryption (HTTPS from proxy to backend) is required. If not re-encrypting, ensure the internal network segment is secure.
Automated Monitoring: Set up alerts for certificate expiration (e.g., via Solution Manager, Zabbix, or SM21/ST22 for errors related to SSL).
Regular Testing: Regularly test HTTPS connections from various client types and browsers.

30 Interview Questions and Answers (One-Liner) for Configuring HTTPS in SAP Basis

Q: What is HTTPS?
- A: HTTP over SSL/TLS, providing encrypted and authenticated communication.
Q: What is the primary transaction used for managing server certificates on SAP ABAP?
- A: STRUST.
Q: What is the purpose of a PSE in SAP?
- A: A Personal Security Environment, a container for cryptographic keys and certificates.
Q: Which SAP cryptographic library is required for SSL/TLS?
- A: CommonCryptoLib (libsapcrypto.so or sapcrypto.dll).
Q: What is the crucial field in a server certificate that must match the client's access URL?
- A: Common Name (CN), which should be the FQDN.
Q: What are the typical default HTTPS ports for SAP ABAP and Java stacks?
- A: 5xx01 for ABAP, 5xx02 for Java (xx is instance number).
Q: How do you generate a Certificate Signing Request (CSR) in STRUST?
- A: Select the PSE, then click "Create Certificate Request" (or "Regenerate Certificate Request").
Q: Where do you import Root and Intermediate CA certificates in STRUST?
- A: Into the "Certificate List" of the respective PSE.
Q: Which profile parameter enables HTTPS on an SAP ICM port?
- A: icm/server_port_0 (with PROT=HTTPS).
Q: What is client certificate authentication?
- A: Both the client and the server authenticate each other using certificates.
Q: Which profile parameter controls client certificate authentication?
- A: icm/HTTPS/verify_client.
Q: What is the primary tool for managing certificates on SAP Java stack?
- A: NetWeaver Administrator (NWA) -> Key Storage.
Q: What is the purpose of ssl/ciphersuites profile parameter?
- A: To restrict the allowed cryptographic algorithms (cipher suites) for security.
Q: What happens if a server certificate expires?
- A: HTTPS connections will fail, and browsers will show security warnings.
Q: Which SAP component often acts as a reverse proxy for HTTPS traffic?
- A: SAP Web Dispatcher.
Q: What is the command-line tool used to manage Web Dispatcher PSEs?
- A: sapgenpse.
Q: Why is time synchronization important for certificate-based communication?
- A: Certificates have validity periods, and time discrepancies can cause validation failures.
Q: What is the benefit of using ssl/minimum_protocol_version?
- A: To disable older, less secure TLS versions (e.g., TLS 1.0, 1.1).
Q: What does PROCTIMEOUT in icm/server_port signify?
- A: The maximum time an ICM work process waits for a response from the backend.
Q: Where are the SSL Client Standard and SSL Server Standard PSEs managed?
- A: In STRUST (ABAP) or NWA Key Storage (Java).
Q: What is the TrustedCAs view in NWA Key Storage for?
- A: Storing trusted Root and Intermediate CA certificates.
Q: What is the main security risk addressed by HTTPS?
- A: Eavesdropping (data interception) and tampering (data modification).
Q: What does PKI stand for?
- A: Public Key Infrastructure.
Q: If SAP is initiating an outgoing HTTPS call, which PSE is primarily used?
- A: SSL Client Standard PSE (or ssl/client_pse).
Q: What error might you see if the certificate CN doesn't match the URL?
- A: NET::ERR_CERT_COMMON_NAME_INVALID or similar browser warnings.
Q: What is the purpose of wdisp/ssl_encrypt = 1 in Web Dispatcher profile?
- A: To force the Web Dispatcher to use HTTPS for communication with backend systems.
Q: How can you restart the ICM in ABAP without restarting the whole system?
- A: Via SMICM transaction -> Administration -> ICM -> Exit Soft -> Global.
Q: What is the role of an Intermediate CA in a certificate chain?
- A: To sign server certificates, thus providing an extra layer of security between the Root CA and the end-entity certificate.
Q: What kind of alert should you set up for certificate management?
- A: Alerts for certificate expiration warnings.
Q: Why should you avoid anonymous access for HTTPS services in SICF?
- A: To ensure authentication and control access to the service.

5 Scenario-Based Hard Questions and Answers for Configuring HTTPS in SAP Basis

Scenario: Users are unable to access your Fiori Launchpad (running on a multi-application server SAP ABAP system behind an SAP Web Dispatcher) via HTTPS. Browsers display NET::ERR_CERT_AUTHORITY_INVALID or ERR_SSL_VERSION_OR_CIPHER_MISMATCH. You've verified that the FQDN in the browser URL matches the Common Name (CN) in the Web Dispatcher's server certificate.
- Q: Diagnose the specific causes for these two distinct error messages. Detail the Basis-level troubleshooting steps for each error, including relevant transactions and configuration areas for the Web Dispatcher and backend ABAP system.
- A:
  - Diagnosis of Error Messages:
    1. NET::ERR_CERT_AUTHORITY_INVALID: This error indicates that the client's browser (or operating system) does not trust the Certificate Authority (CA) that issued the Web Dispatcher's server certificate. This typically happens if the Root CA or an Intermediate CA certificate in the certificate chain is missing or not properly imported into the Web Dispatcher's PSE, or if the client's trust store doesn't contain the necessary Root/Intermediate CAs.
    2. ERR_SSL_VERSION_OR_CIPHER_MISMATCH: This error indicates a negotiation failure during the SSL/TLS handshake. This means the client and server (Web Dispatcher in this case) could not agree on a common, mutually supported TLS protocol version (e.g., client only supports TLS 1.2, server only offers TLS 1.0/1.1 or 1.3) or a common cryptographic cipher suite. This is often due to restrictive security configurations.
  - Basis-Level Troubleshooting Steps:
    
    For NET::ERR_CERT_AUTHORITY_INVALID (Certificate Chain/Trust Issue):
    1. Web Dispatcher PSE Chain Verification (sapgenpse):
      - Action: Go to the Web Dispatcher server (OS level). Use sapgenpse get_my_name -p <WebDisp_PSE_path> to verify the Web Dispatcher's server certificate CN.
      - Action: Use sapgenpse get_my_cert -p <WebDisp_PSE_path> or a command to export the certificate chain. Crucially, manually inspect the exported .cer file to ensure the entire certificate chain (Web Dispatcher Cert -> Intermediate CA -> Root CA) is present.
      - Troubleshooting: If the chain is incomplete, go back to the CA and request the full chain or download individual Intermediate/Root CA certificates.
    2. Import Missing CAs into Web Dispatcher PSE (sapgenpse):
      - Action: If intermediate or root CA certificates are missing in the Web Dispatcher's PSE, import them using sapgenpse maintain_pk -a <CA_Cert.cer> -p <WebDisp_PSE_path>. Repeat for all missing CAs in the chain.
      - Restart: Restart the Web Dispatcher after changes (sapwebdisp -restart).
    3. Client Trust Store (Browser/OS):
      - Action: On a problematic client, try accessing the URL. If the error persists, import the Root CA certificate (and any Intermediate CA certificates) into the client's browser trust store or OS certificate store.
      - Rationale: Even if the Web Dispatcher sends a complete chain, the client must ultimately trust the Root CA.
    For ERR_SSL_VERSION_OR_CIPHER_MISMATCH (Protocol/Cipher Mismatch):
    1. Web Dispatcher Profile Parameter Review (sapwebdisp.pfl):
      - Action: Check the Web Dispatcher profile (sapwebdisp.pfl). Look for:
        
        ssl/ciphersuites: Is it overly restrictive? Temporarily remove or set to 0 (use default strong ones) for testing if unsure.
        
        ssl/minimum_protocol_version: Is it set too high (e.g., TLS1.3) while the client (browser) only supports TLS1.2 or lower? Try setting it to TLS1.2 or commenting it out temporarily.
      - Restart: Restart the Web Dispatcher after any profile parameter changes.
    2. Backend ABAP System ICM Profile Parameters (DEFAULT.PFL, <SID>_DVEBMGSxx_<host>.pfl):
      - Action: If the Web Dispatcher forwards HTTPS to the backend (re-encryption), verify the same parameters (ssl/ciphersuites, ssl/minimum_protocol_version) on the backend ABAP system(s) in RZ10.
      - Rationale: A mismatch between Web Dispatcher and backend can cause issues even if the front-end works.
      - Restart: Perform a soft ICM restart (SMICM -> Administration -> ICM -> Exit Soft -> Global) after changing parameters in RZ10.
    3. Client Browser Compatibility:
      - Action: Test with different browsers and browser versions. Older browsers might not support modern TLS versions or strong cipher suites.
      - Rationale: Confirm if the issue is client-specific.
    4. SSLLabs Test:
      - Action: Use an external tool like SSLLabs SSL Server Test (https://www.ssllabs.com/ssltest/) to analyze your Web Dispatcher's SSL configuration (supported protocols, cipher suites, certificate chain). This provides a comprehensive diagnosis.
Scenario: Your SAP Basis team manages several SAP systems (ABAP and Java). You've just received notifications that the server certificates for both your Production ABAP system (used for Fiori) and your Production Java system (used for Solution Manager Diagnostics Agent - SMDA) are due to expire in 30 days. You need to perform a renewal without impacting production.
- Q: Detail the step-by-step process for renewing the server certificates for both the ABAP and Java production systems. Emphasize how you would minimize downtime, handle multi-application server ABAP environments, and ensure no disruption to connected services like SMDA.
- A:
  
  General Strategy for Renewal:
  - Generate CSR: Generate a new CSR from the existing PSE/Key Store.
  - Get Signed: Send to CA, get new signed certificate.
  - Import: Import the new certificate into the existing PSE/Key Store.
  - Activate: Activate the changes (usually requires service/instance restart).
  - No Downtime if Existing PSE is Used: If you import the new certificate into the same PSE/Key Store that has the current valid certificate, there is usually no downtime as the application servers can continue using the old certificate until the new one is loaded. Only a soft restart of ICM (ABAP) or the SSL service (Java) is needed.
  A. SAP ABAP Production System Certificate Renewal (Fiori):
  1. Preparation (30+ days before expiration):
    - Identify PSE: Determine which PSE in STRUST is used for Fiori (typically SSL Server Standard).
    - Backup PSE: Export a copy of the existing PSE (right-click on SSL Server Standard -> Export PSE to file) and securely store it. This is a crucial rollback point.
    - Check CA Chain: Ensure you have all necessary Root and Intermediate CA certificates readily available.
    - Communicate: Inform stakeholders (e.g., security team, Fiori users, network team) about the renewal.
  2. Generate CSR (STRUST):
    - Go to STRUST. Select SSL Server Standard PSE.
    - Click "Regenerate Certificate Request". Confirm details (especially CN/FQDN).
    - Save the CSR file locally.
  3. Submit to CA: Send the new CSR file to your CA.
  4. Import Certificate Response (STRUST):
    - Once the new server certificate is received from the CA, go to STRUST. Select the SSL Server Standard PSE.
    - Click "Import Certificate Response" and select the new certificate file. This imports the new certificate into the existing PSE alongside the old one.
    - Import/Verify CA Chain: Ensure the entire, latest CA chain is correctly present in the PSE's "Certificate List". If the CA chain changed, re-import.
    - Save: Save the changes to the PSE.
  5. Distribute and Activate (Multi-App Server):
    - Action: In STRUST, after saving, select the SSL Server Standard PSE. Go to PSE -> Distribute. This will distribute the updated PSE to all active application servers in the system.
    - Activate on All ICMs: For each application server instance, go to SMICM -> Administration -> ICM -> Exit Soft -> Global. This performs a soft restart of the ICM, which will load the new certificate without restarting the entire SAP instance.
    - Rationale for Soft Restart: The ICM reloads its configuration, including the PSE. The old certificate will be used until the new one is active. This minimizes disruption.
  6. Verification:
    - Test Fiori Launchpad access from browsers (check certificate details).
    - Monitor SM21, ST22, dev_icm logs for any SSL/certificate-related errors.
    - Verify STRUST shows the new certificate as active.
  B. SAP Java Production System Certificate Renewal (SMDA):
  1. Preparation (30+ days before expiration):
    - Identify Key Store: In NWA (/nwa), navigate to Configuration -> Security -> Certificates and Keys -> Key Storage. The SMDA agent uses the ICM_SSL_<SID> entry in the Default view.
    - Export Key Store: Export a copy of the existing ICM_SSL_<SID> key store entry.
    - Check CA Chain: Ensure you have necessary Root and Intermediate CA certificates.
  2. Generate CSR (NWA):
    - In NWA Key Storage, Default view, select ICM_SSL_<SID>.
    - Click "Generate Key Pair and CSR Request". Confirm details.
    - Download the CSR file.
  3. Submit to CA: Send the new CSR file to your CA.
  4. Import Certificate Response (NWA):
    - Once the new certificate is received, in NWA Key Storage, Default view, select ICM_SSL_<SID>.
    - Click "Import Certificate Response" and select the new certificate file. This updates the existing entry.
    - Import/Verify CA Chain: Ensure the entire, latest CA chain is correctly present in the TrustedCAs view.
  5. Activate & Verification:
    - Restart Service: Navigate to Configuration -> Infrastructure -> Java System Properties -> Services. Select com.sap.engine.services.ssl.manager and restart it. This applies the new certificate.
    - SMDA Check: Verify SMDA connection status in Solution Manager.
    - Test access to Java applications via HTTPS.
    - Monitor default trace files for any SSL errors.
Scenario: Your company requires an extremely high level of security for specific web services published by your SAP ABAP system. Instead of traditional username/password or SAML authentication, they demand client certificate authentication for these services.
- Q: Detail the end-to-end configuration steps required on the SAP ABAP system to implement client certificate authentication for a specific SICF service. Include necessary profile parameters, STRUST configuration, and user mapping considerations.
- A:
  
  End-to-End Configuration for Client Certificate Authentication (ABAP):
  
  Phase 1: SAP System Preparation
  1. Cryptographic Library: Ensure CommonCryptoLib is correctly installed and configured (profile parameters ssl/ssl_lib, sec/libsapsecu).
  2. HTTPS Port: Ensure an ICM HTTPS port is active (icm/server_port_x = PROT=HTTPS, ...) in RZ10.
  3. SSL Server Standard PSE: Ensure your SSL Server Standard PSE in STRUST is correctly configured with a valid server certificate and its full CA chain. This is for the server to present its identity to the client.
  Phase 2: Configure Client Certificate Verification (SAP as Server)
  1. Set icm/HTTPS/verify_client Profile Parameter:
    - Action: In RZ10, set icm/HTTPS/verify_client = 2 (required) in the relevant instance profile. This mandates that clients must present a certificate. Alternatively, set to 1 (optional) if some clients will still use username/password.
    - Restart: Perform a soft restart of ICM (SMICM -> Administration -> ICM -> Exit Soft -> Global).
  2. Import Client CA Certificates into SSL Server Standard PSE (STRUST):
    - Action: Obtain the Root CA certificate (and any Intermediate CA certificates) that will issue the client certificates.
    - Action: In STRUST, select the SSL Server Standard PSE. Click "Import Certificate" (yellow folder icon) and import each client CA certificate. Then click "Add to Certificate List" (green checkmark).
    - Save: Save the changes to the PSE.
    - Rationale: The SAP system needs to trust the CA that signed the client certificates to validate them.
  Phase 3: User Mapping (Connecting Client Certificate to SAP User)
  1. Map Client Certificate to SAP User (SU01):
    - Action: For each SAP user who will authenticate via a client certificate:
      - Go to SU01, enter the user ID.
      - Go to the "SNC" tab.
      - Click the "Certificate" button.
      - Click "Import Certificate" and select the individual client certificate (not the CA certificate) for that user.
      - Confirm the mapping.
    - Rationale: This links the unique identity in the client certificate (Distinguished Name - DN) to a specific SAP user ID.
  Phase 4: Configure Specific SICF Service
  1. Activate and Configure SICF Service (SICF):
    - Action: Go to SICF. Navigate to the specific web service path (e.g., /sap/bc/web_service_path).
    - Service Properties: Double-click the service.
      - Go to the "Logon Data" tab.
      - For "Procedure," select "Standard."
      - For "Authentication," select "Client Certificate (SSL)." Deselect other authentication methods (e.g., Basic Authentication) if not needed.
      - Save.
    - Activate: Ensure the SICF service and its parent nodes are active.
  Phase 5: Client-Side Configuration (Coordination with Client Teams)
  1. Client Certificate Provisioning: Ensure end-users or client applications have valid client certificates (issued by the trusted CA) installed in their browser's/application's certificate store.
  2. Browser/Client Configuration:
    - Browsers usually prompt the user to select a certificate if multiple are available.
    - External applications might need specific configuration to present the client certificate during the HTTPS handshake.
  Phase 6: Testing and Monitoring
  1. Test Access: Attempt to access the SICF service via HTTPS from a client configured with a valid certificate. Verify successful logon.
  2. Monitor Logs: Check dev_icm logs, SM21, and SM20N (Security Audit Log) for successful logon events via certificate and any errors.
Scenario: You are implementing a new Fiori Launchpad on your existing SAP S/4HANA system. The Fiori Launchpad will be accessed publicly, and you want to ensure optimal performance and security. You plan to use an SAP Web Dispatcher as a reverse proxy, and it will handle the external HTTPS connection. Internally, between the Web Dispatcher and the S/4HANA backend, you are debating between re-encrypting with HTTPS or using HTTP.
- Q: Discuss the security and performance implications of using HTTPS vs. HTTP between the SAP Web Dispatcher and the backend S/4HANA system for Fiori traffic. What is the recommended approach for a public-facing system, and what specific Basis configuration parameters and considerations are involved in securing this internal communication?
- A:
  
  Security and Performance Implications:
  - Option 1: HTTPS (Web Dispatcher -> Backend) - Recommended for Public-Facing Systems
    - Security Implications:
      - Pros: Provides end-to-end encryption. Even if an attacker gains access to the internal network segment between the Web Dispatcher and backend, the data remains encrypted. This is crucial for sensitive data and compliance. Prevents internal eavesdropping and tampering.
      - Cons: Higher CPU overhead on both Web Dispatcher and backend application servers due to encryption/decryption operations. Introduces a second SSL/TLS handshake.
    - Performance Implications:
      - Cons: Marginal performance overhead due to the additional encryption layer. This overhead is generally acceptable and often negligible on modern hardware, especially when balanced against security benefits.
    - Recommendation: Highly Recommended for any public-facing system or systems handling sensitive data, regardless of location (internal/external). The security benefits far outweigh the minor performance overhead.
  - Option 2: HTTP (Web Dispatcher -> Backend)
    - Security Implications:
      - Pros: Lower CPU overhead as no encryption/decryption occurs.
      - Cons: Significant Security Risk. Data is transmitted in clear text between the Web Dispatcher and the backend. If the internal network segment is compromised, data can be easily intercepted, read, and even modified. This violates confidentiality and integrity.
    - Performance Implications:
      - Pros: Slightly better performance due to no encryption overhead.
    - Recommendation: NOT Recommended for public-facing systems or any system handling sensitive data. Only acceptable in very rare scenarios (e.g., highly secured, isolated, internal network with no sensitive data).
  Recommended Approach for Public-Facing System:
  - End-to-End HTTPS: Use HTTPS from the client to the Web Dispatcher, and then re-encrypt with HTTPS from the Web Dispatcher to the backend S/4HANA system.
  Specific Basis Configuration Parameters and Considerations for Securing Internal Communication:
  
  1. SAP Web Dispatcher Configuration (sapwebdisp.pfl):
  - Incoming HTTPS (External):
    - icm/server_port_0 = PROT=HTTPS, PORT=443, TIMEOUT=600, HOST=<Public_WD_FQDN> (defines the external-facing HTTPS port)
    - Certificate: Ensure the Web Dispatcher's server certificate (in its PSE, managed by sapgenpse) has its CN matching the public FQDN (e.g., fiori.mycompany.com).
  - Outgoing HTTPS (Internal to Backend):
    - wdisp/ssl_encrypt = 1: Crucial parameter. Forces the Web Dispatcher to use HTTPS when communicating with backend systems.
    - wdisp/ssl_auth = 0 (or 1 for optional, 2 for required): Controls client certificate authentication from WD to backend. 0 (no client cert) is common unless specific internal client cert authentication is required.
    - icm/client_sni_enabled = true: If backend servers use SNI.
    - ssl/client_pse: Ensure the Web Dispatcher's SSL Client Standard PSE (or ssl/client_pse) in its profile is correctly configured. This PSE is used when the Web Dispatcher acts as an SSL client.
    - Backend CA Trust: The Web Dispatcher's SSL Client Standard PSE must trust the CA that issued the backend S/4HANA system's server certificate. This means importing the backend's Root and Intermediate CAs into the Web Dispatcher's client PSE using sapgenpse.
  2. Backend SAP S/4HANA ABAP System Configuration (DEFAULT.PFL, instance profiles):
  - Incoming HTTPS (Internal from Web Dispatcher):
    - icm/server_port_1 = PROT=HTTPS, PORT=80$(SAPSYSTEMNAME)1, TIMEOUT=600, PROCTIMEOUT=600, HOST=<Internal_S4H_FQDN> (or an internal virtual hostname)
    - Certificate: Ensure the S/4HANA ABAP system's server certificate (in its SSL Server Standard PSE in STRUST) has its CN matching its internal FQDN (e.g., s4h.internal.mycompany.com).
    - CA Chain: Ensure the full CA chain is correctly imported into the SSL Server Standard PSE.
    - icm/HTTPS/verify_client: Set to 0 if Web Dispatcher is not presenting a client certificate, or 1/2 if it is.
  - Session Management (for Fiori):
    - login/ticket_expiration_time: Set appropriate ticket validity for Fiori SSO.
    - http/security_session_timeout: Timeout for HTTP security session.
  3. Security Best Practices:
  - Strict Firewalls: Implement robust firewalls to protect the internal network segment between Web Dispatcher and backend, even if using HTTPS.
  - No Direct Backend Access: Prevent direct client access to the backend S/4HANA system's HTTPS port; all Fiori traffic should go through the Web Dispatcher.
  - Strong Cipher Suites/TLS Versions: Configure ssl/ciphersuites and ssl/minimum_protocol_version on both Web Dispatcher and backend to use only strong, modern encryption.
Scenario: Your SAP Basis team has been tasked with hardening the security posture of your production SAP landscape. A key part of this involves ensuring that all critical external-facing web services (exposed via SICF, used by third-party integrations) use only the most secure TLS protocol version (TLS 1.2 or higher) and strong cipher suites, and that older, vulnerable protocols/ciphers are strictly disabled.
- Q: Detail the step-by-step process for enforcing TLS 1.2+ and strong cipher suites across your SAP ABAP web services, including how to identify current settings, implement changes, and verify the new security posture. What are the potential risks and compatibility issues you might encounter, and how would you mitigate them?
- A:
  
  Step-by-Step Process for Enforcing TLS 1.2+ and Strong Cipher Suites:
  
  Phase 1: Assessment and Planning (Before Implementation)
  1. Identify Current Settings (ABAP ICM):
    - Action: Go to SMICM -> Goto -> Parameters -> Display. Check ssl/minimum_protocol_version and ssl/ciphersuites. Note their current values. If they are not set, defaults (which might be weaker) are used.
    - Action: Use an external SSL scanner (e.g., SSLLabs SSL Server Test) on your public-facing SAP FQDN to get a detailed report of currently supported protocols and ciphers. This helps identify actual active settings.
  2. Define Target Security Policy:
    - TLS Version: Decide on the minimum TLS version (e.g., TLS1.2). Note that TLS1.3 requires specific kernel/CommonCryptoLib versions.
    - Cipher Suites: Select a list of strong, modern cipher suites (e.g., 135:PFS:HIGH::EDH:SHA2). Refer to SAP Note 510007 (or newer relevant notes) for recommended values for your specific SAP kernel/CCL version. Avoid ALL, DEFAULT, LOW, MEDIUM.
  3. Identify Impacted Systems/Clients:
    - Action: List all external-facing systems/clients that consume your SAP web services.
    - Coordination: Communicate the upcoming changes to the owners of these third-party integrations. They must ensure their client applications support the new, stricter TLS versions and cipher suites. This is the most critical step to prevent service disruption. Older clients (e.g., legacy Java applications, outdated .NET frameworks, old OS/browsers) might only support TLS 1.0/1.1 and will break.
  Phase 2: Implementation (Scheduled Downtime or Controlled Window)
  1. Backup Profile Parameters:
    - Action: Before making changes in RZ10, backup your existing default and instance profiles.
  2. Configure Profile Parameters (RZ10):
    - Action: Go to RZ10. Edit the DEFAULT.PFL (or specific instance profiles if you need different settings per app server).
    - Set ssl/minimum_protocol_version: Add/Change to TLS1.2 (or TLS1.3 if supported and desired).
    - Set ssl/ciphersuites: Add/Change to your chosen strong cipher string (e.g., 135:PFS:HIGH::EDH:SHA2).
    - Save and Activate: Save the profile changes and activate them.
  3. Restart ICM:
    - Action: For the changes to take effect, perform a soft restart of the ICM on all relevant application servers (SMICM -> Administration -> ICM -> Exit Soft -> Global). A full system restart is generally not required for these parameters.
  Phase 3: Verification and Post-Implementation
  1. Internal Verification:
    - Action: After the ICM restart, check SMICM -> Goto -> Parameters -> Display again to confirm the new values are active.
    - Action: Use SMICM -> Goto -> Services and check the "SSL/TLS Protocol" column for the HTTPS port, it should reflect the new minimum version.
  2. External Verification:
    - Action: Re-run the external SSL scanner (e.g., SSLLabs) on your FQDN. Verify that TLS 1.0, 1.1 are no longer supported, and only your explicitly configured strong cipher suites are available.
  3. Functional Testing:
    - Action: Perform thorough functional testing of all critical web services (especially those used by third-party integrations) from test clients that are known to support TLS 1.2+/strong ciphers.
    - Action: Monitor dev_icm logs, SM21, and ST22 for any new SSL handshake errors (e.g., SSL_PROTOCOL_ERROR, SSL_CIPHER_MISMATCH).
  Potential Risks and Compatibility Issues & Mitigation:
  1. Client Incompatibility:
    - Risk: Older browsers, legacy client applications, or systems running outdated OS versions (e.g., Windows Server 2008 R2 without specific KBs, very old Java versions) may not support TLS 1.2 or the chosen strong cipher suites. This will cause connection failures.
    - Mitigation: Thoroughly identify and test with all client types during planning. If older clients must connect, consider a tiered approach (e.g., a separate Web Dispatcher instance or a proxy that can bridge protocols, which is not ideal but might be a temporary workaround). The best solution is to upgrade the client-side software.
  2. Overly Restrictive Cipher Suites:
    - Risk: Selecting a cipher suite string that is too restrictive might lead to no common cipher suite being found between client and server, even if TLS version is compatible.
    - Mitigation: Start with SAP-recommended strong cipher suites from relevant SAP Notes. Use SSLLabs to analyze and adjust. Gradually remove weaker ciphers.
  3. Certificates:
    - Risk: Issues with the certificate chain (missing intermediate CA) can cause "Untrusted" errors even if TLS/cipher are fine.
    - Mitigation: Always ensure the full certificate chain is imported into the PSE.
  4. Performance Impact:
    - Risk: While generally acceptable, increased CPU utilization due to stricter encryption might occur, especially on high-volume systems or older hardware.
    - Mitigation: Monitor CPU utilization closely after implementation. Scale out (add application servers) or scale up (more CPU/RAM) if performance becomes a bottleneck. Consider offloading SSL/TLS to a hardware load balancer for high-volume public-facing systems.

Rakshit Ranjan Singh

Search This Blog