Hi Jeff, it is unclear if you understood the dependency between
- the the snc/identity/as parameter
- the subject of a server's own certificate in SNC SAPCryptolib PSE (STRUST)
- Entries in SNC0
- The AD account's SPN attribute
FQDN is just completely irrelevant for SNC.
One example how I would do configuration:
First system: ABC (calling)
Second System: XYZ (called)
(The example is based on CommonCryptolib or Secure Login Library with Secure Login Client or SNC Client Encryption)
Configuration of System ABC:
- snc/identity/as = p:CN=systemABCcn
- SNC SAPCryptolib PSE Sybject= CN=systemABCcn
- AD account's SPN=SAP/systemABCcn
Configuration of system XYZ
- snc/identity/as= p:CN=systemXYZcn
- SNC SAP Cryptolib PSE Subject: CN=systemXYZcn
- AD account's SPN=SAP/systemXYZcn
- SNC0: include an entry
- System ID = ABC
- SNC name = p:CN=systemABCcn
To enable trust you have to export both certificates and import each into the other system's SNC SAPCryptolib PSE's Certificate list. You obviously did this.
Instead you could get both certificates signed by a CA and only import your CA's root certificate into the certificate list.
We only have one SNC SAPCryptolib PSE per system even if we have many application servers. I don't think you will get it work with one PSE per application server but I never tried. I am not sure if you tried this.
Since you seem to already have GUI-SNC (SAP SSO/SNC Client Encryption with Kerberos?) up and running you will have to start with your existing snc/identity/as and derive your certificate's subject from them. There are some implicit rules which SPN will match which snc/identity/as and subject. You might have to adhust your snc/identity/as parameters. You will find documentation on this here:
If you are not using SAP SSO or SNC Client Encryption this will get more interesting (and I will be out).
Regards,
Lutz