Fixing RPC_E_FULLSIC_REQUIRED (0x80010121) SSL error

You're staring at this error and your app won't connect. Let's fix it.

The error RPC_E_FULLSIC_REQUIRED (0x80010121) with the message “Full subject issuer chain Secure Sockets Layer (SSL) principal name expected from the server” usually shows up in Outlook connecting to Exchange over RPC over HTTPS, or in custom apps using RPC over HTTP. I've seen it mostly on IIS servers after a certificate renewal or when you're using a certificate from a public CA that doesn't include the full chain.

The real fix: disable client certificate mapping

Ninety percent of the time, this error isn't about your certificate being bad—it's about IIS being configured to require client certificate mapping but not getting the full chain from the client. The fastest fix is to turn that off on the virtual directory hosting RPC.

1. Open IIS Manager on your Exchange or RPC server.
2. Go to the virtual directory that's serving RPC — usually /Rpc or /EWS.
3. Open SSL Settings.
4. Under Client Certificates, select Ignore instead of Accept or Require.
5. Click Apply, then run iisreset from an admin command prompt.

I had a client last month whose entire Outlook connectivity died after they migrated to a new CA. This was the fix, and it took me longer to walk to the server room than to make the change.

Why this works

When IIS is set to Accept client certificates, it tries to validate the full chain—including the issuer's issuer. If the client (like Outlook) only sends its leaf certificate without the intermediate CAs, the server throws RPC_E_FULLSIC_REQUIRED. Setting it to Ignore tells IIS not to ask for a client certificate at all, so it never gets to that chain validation step. The RPC traffic then uses server-side authentication only, which is fine for most setups.

Less common variations and edge cases

1. The server certificate is missing intermediate CAs

If you're using a certificate from a public CA like DigiCert or Let's Encrypt, your server might not be sending the full chain. Check the certificate in MMC or run this PowerShell:

Get-ChildItem Cert:\LocalMachine\My | Where-Object {$_.Subject -like "*yourdomain*"} | Select-Object Subject, EnhancedKeyUsageList

If the Issuer field shows an intermediate CA (like “R3” for Let's Encrypt), you need to install that intermediate certificate. Download it from your CA's site, install it into the Intermediate Certification Authorities store, then bind it in IIS under Server Certificates → View → check “Include all certificates in the certification path”.

2. The client certificate itself is malformed

Sometimes the certificate on the client side (if you're using client cert authentication) doesn't include the full chain. Re-export it from the CA with “Include all certificates in the certification path” checked. Had a user once who exported from a browser and only got the leaf—took me an hour to figure out why RPC kept failing.

3. Schannel registry tweak

For stubborn cases, you can tell Windows to send the full chain by default. This is a registry change that affects all SSL/TLS connections:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"SendTrustedIssuerList"=dword:00000001
"ClientAuthTrustMode"=dword:00000001

Reboot after applying. I don't usually recommend this unless you've already tried the IIS fix and it didn't stick.

Prevention

To keep this from popping up again on renewals or new servers:

• Always install the full certificate chain — don't just bind the .cer file. Use the .pfx or .p7b with all intermediates.
• Test client cert behavior before rolling out to everyone. Use SSL Labs or openssl s_client -connect yourserver:443 -showcerts to verify the chain is complete.
• Document your IIS SSL settings for any RPC virtual directories. I've seen teams forget they set “Accept” two years ago and then wonder why a CA change breaks everything.

That's it. Nine out of ten times it's the IIS setting. If not, check the chain. You'll be back online in minutes.