Solution: These two steps out of all steps listed below solved my issue.
1. Assign the right in the Local security group too and
2. Grant “Log on as Batch Job” permission to the application pool identity account

- The account used as application pool identity shouldn’t be locked
- Reset the password of the application pool identity account in case it is expired
- Switch from built-in account to domain account for application pool identity
- Use another domain account as application pool identity
- Give “Full Control” to application pool identity account on shared data and configuration folders
- Give “Log on as Batch Job” permission to the application pool identity account
- Add the application pool identity account to IIS_USRS group
- Check account information in applicationHost.config for possible typos
- Recreate application pools, websites, and shared configuration (if used)
- Make sure to use the same encryption provider (IISWASOnlyCngProvider or IISCngProvider) in applicationHost.config
- Change application pool process model from LogonBatch to LogonService
- If it is a shared configuration setup in IIS, use the same IISWASKey

See links for more details
– https://techcommunity.microsoft.com/t5/IIS-Support-Blog/Event-ID-5059-Application-pool-has-been-disabled/ba-p/305274
– https://support.office.com/en-gb/article/change-passwords-for-web-application-pools-f7a944ec-3748-4478-8f53-df5569c965b5

I’m going to highlight only the important steps for HTTPS communication.

• A client contacts the server.
• The client and server exchange information about the communications they intend to perform, such as the ciphers to use (SSL handshake).
• The server transmits its certificate to the client.
  Note: It depends on the protocol used here as the server only can send its certificate etc.
• The client checks that it trusts the certification authority that issued the certificate. If it does not recognize the CA and does not get an override, the communication ends.
• The client checks for revocation information on the certificate. If the certificate is revoked or revocation information is unavailable, then the client might attempt to obtain an override. Implementations vary on how they deal with null or unreachable CRL information, but almost all will refuse to communicate with any entity using a revoked certificate.
• The client generates a portion of a temporary key for symmetric encryption.
• The client uses the server’s public key to encrypt the partial temporary key.
• The client sends the encrypted partial key to the server.
• The server decrypts the partial key using its own private key.
• The server completes the secret key.
• The client and server agree to use the secret key. All communications in the same conversation are encrypted with that key.

Note: It would be possible to use asymmetric encryption for the entire conversation. However, as we talked about earlier, asymmetric encryption results in ciphertext that greatly exceeds the size of the unencrypted source. To solve that problem without exposing a plaintext key, SSL only uses asymmetric encryption while the client and server establish identity and work together to create a symmetric shared key. From that point forward, they only use symmetric encryption. That keeps the size of transmitted data to a minimum. Even better, if an attacker manages to break any point of the transmission besides the initial negotiation, they will only gain a temporary key.

All of that explains why we use suites of ciphers: we need multiple algorithms to make this work.