sssd fails to parse user certificate

[MadCatX]

I have been trying to set up sssd with my AD DC so that I could log into my Linux workstation with pam_sss. After some troubleshooting while trying to figure out why I would always get

Please insert smart card
Please (re)insert (different) Smartcard
Please (re)insert (different) Smartcard

Error messages I found this in the sssd_pam.log file

   *  (2025-11-10 18:18:47): [pam] [parse_p11_child_response] (0x4000): [CID#1] Found toke
n name [YubiKey PIV #27084174].
   *  (2025-11-10 18:18:47): [pam] [parse_p11_child_response] (0x4000): [CID#1] Found modu
le name [/usr/lib/libykcs11.so].
   *  (2025-11-10 18:18:47): [pam] [parse_p11_child_response] (0x4000): [CID#1] Found key 
id [01].
   *  (2025-11-10 18:18:47): [pam] [parse_p11_child_response] (0x4000): [CID#1] Found labe
l [X.509 Certificate for PIV Authentication].
   *  (2025-11-10 18:18:47): [pam] [parse_p11_child_response] (0x4000): [CID#1] Found cert
 [MIIGaDCCBFCgAwIBAgICEBAwDQYJKoZIhvcNAQELBQAwgYcxCzAJBgNVBAYTAkNaMQ8wDQYDVQQIDAZQcmFndWUx
DzANBgNVBAcMBlByYWd1ZTElMCMGA1UECgwcVERDIChJTlRFUk5BTCBDQSAtIEtlcmJlcm9zKTEPMA0GA1UEAwwGdG
RjLmN6MR4wHAYJKoZIhvcNAQkBFg9vdmVybG9yZEB0ZGMuY3owHhcNMjUxMTA0MDkzOTU1WhcNMjYxMTA0MDkzOTU1
WjBVMQswCQYDVQQGEwJDWjEPMA0GA1UECAwGUHJhZ3VlMSUwIwYDVQQKDBxUREMgKElOVEVSTkFMIENBIC0gS2VyYm
Vyb3MpMQ4wDAYDVQQDDAVtbWFseTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAKsMM4J0DtpbWs3Tb30z
Yp196ngojogjbQpbaUqXgJNqkzSe7nnzVA1R1LUYWdONFkstbsL3zRCDYckURp0XaSnJ/YgsPRwVVgJdtfdwZ/smpn
MSmTmGJ+U9Kk3i6G02uOqOR/B+PllrtUdRkThVs4s477K5wxAUkMZCcrJzva8ElSw2L9oo9/G1j/1qVhuEB3CbkyHe
Nxk13ibeTrpUWPaylvMm+WWHcjfmFh0HrNG2vFCMFAp3gbso62ulaX8c/RYMLUvA0owS50oYDRu91rQOEP81BzzggG
mspLpCtQjIjPCZd+57sc9v5DPFvXqTjcdjnvmgyZCjtyevLoR60MpFHCH9hwXDjtPJWjDdMplwI3fUZT4JkCk12tL2
W7FznUQJxEItACCJ210HvtBcZzjowgjODs5U8lCL2gy/iYO15TiCd4NgmycGbHOymqO5pbxFXcwzUgOBxtoLCSp8el
SsCgyqjWKbpaUkTddpI24Fz7rpUKFtufkdsQuf/H2smKQqikfIcX8ogm+1uAlZr4Jq00S2Po49CcAR4ffgqzlP0cF9
pSJILvIp1+PmaE9KUpdB8aZ7RM41/KTKS4NMSvflO/Dd5sqaKfa46nqgTJPj6M2PoMbcykVT+d9J0ZRjQGC1mJkPIK
zkoO1aucB0MMV+LHWeBm/b6u4fMaZ7tpBFAgMBAAGjggENMIIBCTAJBgNVHRMEAjAAMA4GA1UdDwEB/wQEAwIFoDAo
BgNVHSUEITAfBggrBgEFBQcDAgYKKwYBBAGCNxQCAgYHKwYBBQIDBDBPBgNVHREESDBGoBwGCisGAQQBgjcUAgOgDg
wMbW1hbHlAVERDLkNaoCYGBisGAQUCAqAcMBqgCAwGVERDLkNaMA6gAwIBATAHDAVtbWFseTAdBgNVHQ4EFgQUs/Vs
oh1FuA1DS63z5M29xeEKkVAwHwYDVR0jBBgwFoAUENjZrasoSXQ4D7AGunGESYV6T9IwMQYDVR0fBCowKDAmoCSgIo
YgaHR0cHM6Ly9jYS50ZGMuY3ova3JiLWNhLmNybC5wZW0wDQYJKoZIhvcNAQELBQADggIBAG1HHcWk/ZQb9i7mQSow
vsheUXvWCpcKfBN4aLlCvR9bazXpLO179PPzQl1o5q/MkpF3cWTvDSfD2E7/0e9f3jc+6FH0BozG0Gny5E0ENlxB9i
hSq92CB8nA8cRUTlYjoJzB8KHUGqjdDKuqeKL9yN4OpHofUeGXBNM9yOMo1G3douKuZP5lJhl4SR+d8kv8SSBebrXX
qq+z0ov51Kn/at456U4rcGck0RMWnmMrgB8CKi/bmRCxBcuMeqrOJChoY/TDDnPIBmV8lSkDDE2L8tBRg1am3YI3XxtgNmamkYRnlSkUru4/utbWC8RZah5XJrRbRbYMYTsgEbzYfVdL7L65VyXZUYfxGVLMn7+G9oovs1/DYeHZG+ibh31ngPFIYi/ne8HokUbs8tLNnMPs2n6J+XzXoHwNyHjWPNHcGpKESgZOdhjarWvg370UdcBK+H0h6ix/dUoMtcVeGp5KmEjNbTDljZ6VxdjFSMIgEOzJYuUgOTf9pqkgUWMuzijVmSlpUNruK36Yg6PF3bZP5zYO550qHtBszARFbID7StB2yqQjaAZVYiOeNqxgCfjkeQcMJ8nB4YJRrSmv+1M3Y7ITr3PoCLrrnr1ezQ/lJE68xruXtMZ22mEuvHCGsgNUpFnwPYpW8P0zpox2JA6GyHorMA68FJvuixynctzf4E1F].
   *  (2025-11-10 18:18:47): [pam] [sss_certmap_match_cert] (0x0040): [CID#1] Failed to get certificate content.
********************** BACKTRACE DUMP ENDS HERE *********************************

Trying to run the certificate through sssctl cert-show results in

[sssd] [sssctl_cert_show] (0x0010): Failed to parsed certificate.

The certificate is on a Yubikey and it works perfectly fine on Windows workstations or with raw kinit. OpenSSL also parses the certificate without any issue. What could be wrong here?

EDIT:
My sssd version is 2.11.1 as packaged by Arch Linux

[sumit-bose]

Hi,

if the above is the unmodified SSSD debug log content, then it looks like there are some unexpected newline-character in the base64 string, the whole string is expected to be in a single log line.

Can you send the output of

/usr/libexec/sssd/p11_child -d 9 --logger=stderr --pre --ca_db=/etc/sssd/pki/sssd_auth_ca_db.pem --verify=no_verification

I'm not sure if the above is the right path to p11_child on Arch Linux so you might have to change it. And if you do not use /etc/sssd/pki/sssd_auth_ca_db.pem to store the CA certificates you might have to change this as well.

bye,
Sumit

[MadCatX]

The log may have gotten a bit corrupted as I was copypasting it around. You should be able to see the issue by running

sssctl cert-show <the_cert_base64>

Even if you make sure that the whole base64 string is a single line, the command will fail. I have checked this multiple times. I also piped the exact same base64 string to base64 -d | openssl x509 -in -text, which works fine.

I will get you the p11_child diagnostics once I'm back in the office.

Thanks!

[MadCatX]

Output of the command you requested is the following:

root@mmaly-ntb / [1]# /usr/lib/sssd/sssd/p11_child -d 9 --logger=stderr --pre --ca_db=/etc/sssd/pki/sssd_auth_ca_db.pem --verify=no_verification
[p11_child[21526]] [main] (0x0400): p11_child started.
[p11_child[21526]] [main] (0x2000): Running in [pre-auth] mode.
[p11_child[21526]] [main] (0x2000): Running with effective IDs: [0][0].
[p11_child[21526]] [main] (0x2000): Running with real IDs [0][0].
[p11_child[21526]] [parse_cert_verify_opts] (0x0020): Found 'no_verification' option, disabling verification completely. This should not be used in production.
[p11_child[21526]] [do_card] (0x4000): Module List:
[p11_child[21526]] [do_card] (0x4000): common name: [p11-kit-trust].
[p11_child[21526]] [do_card] (0x4000): dll name: [/usr/lib/pkcs11/p11-kit-trust.so].
[p11_child[21526]] [do_card] (0x4000): Description [/etc/ca-certificates/trust-source] Manufacturer [PKCS#11 Kit] flags [1] removable [false] token present [true].
[p11_child[21526]] [do_card] (0x4000): Description [/usr/share/ca-certificates/trust-source] Manufacturer [PKCS#11 Kit] flags [1] removable [false] token present [true].
[p11_child[21526]] [do_card] (0x4000): common name: [yubikey-piv].
[p11_child[21526]] [do_card] (0x4000): dll name: [/usr/lib/libykcs11.so].
[p11_child[21526]] [do_card] (0x4000): Description [Yubico YubiKey OTP+FIDO+CCID 00 00] Manufacturer [Yubico (www.yubico.com)] flags [7] removable [true] token present [true].
[p11_child[21526]] [do_card] (0x4000): Token label [YubiKey PIV #27084174].
[p11_child[21526]] [do_slot] (0x4000): Found [YubiKey PIV #27084174] in slot [Yubico YubiKey OTP+FIDO+CCID 00 00][0] of module [1][/usr/lib/libykcs11.so].
[p11_child[21526]] [do_slot] (0x4000): Login NOT required.
[p11_child[21526]] [read_certs] (0x4000): found cert[X.509 Certificate for PIV Authentication][/C=CZ/ST=Prague/O=TDC (INTERNAL CA - Kerberos)/CN=mmaly]
[p11_child[21526]] [read_certs] (0x4000): found cert[X.509 Certificate for PIV Attestation][/CN=YubiKey PIV Attestation]
[p11_child[21526]] [do_slot] (0x4000): (null) /usr/lib/libykcs11.so (null) YubiKey PIV #27084174 (null) - no label given- 19.
[p11_child[21526]] [do_slot] (0x4000): uri: pkcs11:library-description=PKCS%2311%20PIV%20Library%20%28SP-800-73%29;library-manufacturer=Yubico%20%28www.yubico.com%29;library-version=2.72;slot-description=Yubico%20YubiKey%20OTP%2BFIDO%2BCCID%2000%2000;slot-manufacturer=Yubico%20%28www.yubico.com%29;slot-id=0;model=YubiKey%20YK5;manufacturer=Yubico%20%28www.yubico.com%29;serial=27084174;token=YubiKey%20PIV%20%2327084174;id=%19;object=X.509%20Certificate%20for%20PIV%20Attestation;type=cert.
[p11_child[21526]] [do_slot] (0x4000): (null) /usr/lib/libykcs11.so (null) YubiKey PIV #27084174 (null) - no label given- 01.
[p11_child[21526]] [do_slot] (0x4000): uri: pkcs11:library-description=PKCS%2311%20PIV%20Library%20%28SP-800-73%29;library-manufacturer=Yubico%20%28www.yubico.com%29;library-version=2.72;slot-description=Yubico%20YubiKey%20OTP%2BFIDO%2BCCID%2000%2000;slot-manufacturer=Yubico%20%28www.yubico.com%29;slot-id=0;model=YubiKey%20YK5;manufacturer=Yubico%20%28www.yubico.com%29;serial=27084174;token=YubiKey%20PIV%20%2327084174;id=%01;object=X.509%20Certificate%20for%20PIV%20Authentication;type=cert.
[p11_child[21526]] [do_slot] (0x4000): Found certificate has key id [19].
[p11_child[21526]] [do_slot] (0x4000): Found certificate has key id [01].
0
YubiKey PIV #27084174
/usr/lib/libykcs11.so
19
X.509 Certificate for PIV Attestation
MIIC9TCCAd2gAwIBAgIJAJXcF5k7Lbf8MA0GCSqGSIb3DQEBCwUAMCUxIzAhBgNVBAMMGll1YmljbyBQSVYgQXR0ZXN0YXRpb24gQiAxMCAXDTI0MTIwMTAwMDAwMFoYDzk5OTkxMjMxMjM1OTU5WjAiMSAwHgYDVQQDDBdZdWJpS2V5IFBJViBBdHRlc3RhdGlvbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALfGsJlUJlSFW9U1LiPJe2J0HEy0wacxa53c0UEexr/ZtgmrIf/CVh8kqE4qpMs5igeyqxqZqLjdNqZZmdYFfHJL6AKSppCcWYnaHN6rSj6OgBpidg9uaQlNx+03fXn7GJHQhWYgvTX9qczmfkqh2rh4a14Bg2ipgBePwwvPUidHSdqytfMgq+H1YzbouamXyHdcpW/OPPOeoTwv+X4fr3bldpwABqHDT/mM/znh16dhQu7QlPFgnG3rNK6ddCIdVuFs+LqYlU7Ute+fQbVp8FiravxczUb1GRRKMNkWGtA6m5P87zyAw8vUbnMlsflj6paHAwOpzXfAT4/Gk65UhqUCAwEAAaMpMCcwEQYKKwYBBAGCxAoDAwQDBQcEMBIGA1UdEwEB/wQIMAYBAf8CAQAwDQYJKoZIhvcNAQELBQADggEBAEsyUM3GxUCWSHliTfcF9+r5BEILfR/52cdpRfaJWSdW+/bHUffdGWRD6PckY3AQBpgap3zBgzE5yq2Kv3A1bnAFo6DHjPCnwaos9hFm/YVidxjWvi0brHwKHHGGQdSmQzLAG7/aabpfaVfEurQDBBUoZAnBxdMPtLaS+HGhAVbTgyh9glZrfqZi/aoM57JB5yBZ8GCzUazN6CdE5TnEs+ooVQXfQNP2wNkM2IMOE/CNXa/UVp9s3JH7hloW/VNoynK5SlMrJ+acoehM3fDM4NgIpE+q8ei8+sjUk8NEdie+vPIEgpS8ZEGX1030kuRfw47GG4CJEN9fbB2jaqzU/Mg=
YubiKey PIV #27084174
/usr/lib/libykcs11.so
01
X.509 Certificate for PIV Authentication
MIIGaDCCBFCgAwIBAgICEBAwDQYJKoZIhvcNAQELBQAwgYcxCzAJBgNVBAYTAkNaMQ8wDQYDVQQIDAZQcmFndWUxDzANBgNVBAcMBlByYWd1ZTElMCMGA1UECgwcVERDIChJTlRFUk5BTCBDQSAtIEtlcmJlcm9zKTEPMA0GA1UEAwwGdGRjLmN6MR4wHAYJKoZIhvcNAQkBFg9vdmVybG9yZEB0ZGMuY3owHhcNMjUxMTA0MDkzOTU1WhcNMjYxMTA0MDkzOTU1WjBVMQswCQYDVQQGEwJDWjEPMA0GA1UECAwGUHJhZ3VlMSUwIwYDVQQKDBxUREMgKElOVEVSTkFMIENBIC0gS2VyYmVyb3MpMQ4wDAYDVQQDDAVtbWFseTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAKsMM4J0DtpbWs3Tb30zYp196ngojogjbQpbaUqXgJNqkzSe7nnzVA1R1LUYWdONFkstbsL3zRCDYckURp0XaSnJ/YgsPRwVVgJdtfdwZ/smpnMSmTmGJ+U9Kk3i6G02uOqOR/B+PllrtUdRkThVs4s477K5wxAUkMZCcrJzva8ElSw2L9oo9/G1j/1qVhuEB3CbkyHeNxk13ibeTrpUWPaylvMm+WWHcjfmFh0HrNG2vFCMFAp3gbso62ulaX8c/RYMLUvA0owS50oYDRu91rQOEP81BzzggGmspLpCtQjIjPCZd+57sc9v5DPFvXqTjcdjnvmgyZCjtyevLoR60MpFHCH9hwXDjtPJWjDdMplwI3fUZT4JkCk12tL2W7FznUQJxEItACCJ210HvtBcZzjowgjODs5U8lCL2gy/iYO15TiCd4NgmycGbHOymqO5pbxFXcwzUgOBxtoLCSp8elSsCgyqjWKbpaUkTddpI24Fz7rpUKFtufkdsQuf/H2smKQqikfIcX8ogm+1uAlZr4Jq00S2Po49CcAR4ffgqzlP0cF9pSJILvIp1+PmaE9KUpdB8aZ7RM41/KTKS4NMSvflO/Dd5sqaKfa46nqgTJPj6M2PoMbcykVT+d9J0ZRjQGC1mJkPIKzkoO1aucB0MMV+LHWeBm/b6u4fMaZ7tpBFAgMBAAGjggENMIIBCTAJBgNVHRMEAjAAMA4GA1UdDwEB/wQEAwIFoDAoBgNVHSUEITAfBggrBgEFBQcDAgYKKwYBBAGCNxQCAgYHKwYBBQIDBDBPBgNVHREESDBGoBwGCisGAQQBgjcUAgOgDgwMbW1hbHlAVERDLkNaoCYGBisGAQUCAqAcMBqgCAwGVERDLkNaMA6gAwIBATAHDAVtbWFseTAdBgNVHQ4EFgQUs/Vsoh1FuA1DS63z5M29xeEKkVAwHwYDVR0jBBgwFoAUENjZrasoSXQ4D7AGunGESYV6T9IwMQYDVR0fBCowKDAmoCSgIoYgaHR0cHM6Ly9jYS50ZGMuY3ova3JiLWNhLmNybC5wZW0wDQYJKoZIhvcNAQELBQADggIBAG1HHcWk/ZQb9i7mQSowvsheUXvWCpcKfBN4aLlCvR9bazXpLO179PPzQl1o5q/MkpF3cWTvDSfD2E7/0e9f3jc+6FH0BozG0Gny5E0ENlxB9ihSq92CB8nA8cRUTlYjoJzB8KHUGqjdDKuqeKL9yN4OpHofUeGXBNM9yOMo1G3douKuZP5lJhl4SR+d8kv8SSBebrXXqq+z0ov51Kn/at456U4rcGck0RMWnmMrgB8CKi/bmRCxBcuMeqrOJChoY/TDDnPIBmV8lSkDDE2L8tBRg1am3YI3XxtgNmamkYRnlSkUru4/utbWC8RZah5XJrRbRbYMYTsgEbzYfVdL7L65VyXZUYfxGVLMn7+G9oovs1/DYeHZG+ibh31ngPFIYi/ne8HokUbs8tLNnMPs2n6J+XzXoHwNyHjWPNHcGpKESgZOdhjarWvg370UdcBK+H0h6ix/dUoMtcVeGp5KmEjNbTDljZ6VxdjFSMIgEOzJYuUgOTf9pqkgUWMuzijVmSlpUNruK36Yg6PF3bZP5zYO550qHtBszARFbID7StB2yqQjaAZVYiOeNqxgCfjkeQcMJ8nB4YJRrSmv+1M3Y7ITr3PoCLrrnr1ezQ/lJE68xruXtMZ22mEuvHCGsgNUpFnwPYpW8P0zpox2JA6GyHorMA68FJvuixynctzf4E1F

[sumit-bose]

Hi,

thank you for the details. It looks like there is an issue with decoding the id-pkinit-san OID 1.3.6.1.5.2.2. At a first glance the ASN.1 data from your certificate looks like expected, so I have to debug further. With which tool did you create the certificate, especially the id-pkinit-san?

bye,
Sumit

[MadCatX]

I used OpenSSL with a configuration that is recommended for certificates intended for use with Windows AD DC and Kerberos implementations available for Linux. The specific version of OpenSSL was 3.0.13. I could post some excerpts from the openssl.cnf that I used if that would help.

[sumit-bose]

I used OpenSSL with a configuration that is recommended for certificates intended for use with Windows AD DC and Kerberos implementations available for Linux. The specific version of OpenSSL was 3.0.13. I could post some excerpts from the openssl.cnf that I used if that would help.

Hi,

yes, that would help, maybe I can integrate it into the SSSD tests.

bye,
Sumit

[MadCatX]

Here is a redacted version of openssl.cnf that I used to generate the troublesome certificate. Mind that the configuration file gets some variables like KDC_NAME from the environment so the environment must set them prior to running OpenSSL.

# =========================
# OpenSSL config for KDC cert (PKINIT) compatible with MIT Kerberos and Samba/Heimdal
# =========================

[ ca ]
default_ca = CA_default

[ CA_default ]
dir = .
certs = $dir/certs
crl_dir = $dir/crl
new_certs_dir = $dir/newcerts
database = $dir/index.txt
serial = $dir/serial
RANDFILE = $dir/.rand
private_key = $dir/krb-ca.key.pem
certificate = $dir/krb-ca.cert.pem
crlnumber = $dir/crlnumber
crl = $dir/krb-ca.crl.pem
crl_extensions = crl_ext
default_crl_days = 365
default_md = sha256
preserve = no
policy = policy_match
copy_extensions = none
# REVIEW THE DEFAULT DAYS POLICY
default_days = 365

[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

[ req ]
default_bits = 4096
distinguished_name = req_distinguished_name
string_mask = utf8only
default_md = sha256
x509_extensions = v3_ca
prompt = no
req_extensions = req_ext

[ req_distinguished_name ]
countryName = XX
stateOrProvinceName = XYZ
localityName = XYZ
organizationName = FooBar
commonName = foobar.org
emailAddress = overlord@foobar.org

[ req_ext ]
subjectAltName = @alt_names # Required for PKINIT (MIT & Heimdal)

[ alt_names ]
DNS.1 = ${ENV::KDC_NAME}.foobar.org # FQDN clients use for the KDC
otherName.1 = 1.3.6.1.5.2.2;SEQUENCE:kdc_princ_name

# =========================
# CERT PROFILES
# =========================

# ---- KDC certificate profile (works for MIT and Heimdal) ----
[ kdc_cert_mit_heimdal ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature, keyEncipherment
# EKUs:
# - 1.3.6.1.5.2.3.5 = id-pkinit-KPKdc (MIT *requires* this for the KDC cert)
# - serverAuth is accepted by Heimdal and harmless for MIT
extendedKeyUsage = serverAuth, 1.3.6.1.5.2.3.5
# SAN must include the KDC's DNS name (used by clients); required by MIT & Heimdal
subjectAltName = @alt_names
# Hygiene
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
# Optional revocation pointers (uncomment and edit if you publish them)
# We will intentionally provide the CRL from a resource *other* than the KDC itself
crlDistributionPoints = URI:https://ca.foobar.org/krb-ca.crl.pem

[kdc_princ_name]
realm = EXP:0,GeneralString:FOOBAR.ORG
principal_name = EXP:1,SEQUENCE:kdc_principal_seq

[kdc_principal_seq]
name_type = EXP:0,INTEGER:1
name_string = EXP:1,SEQUENCE:kdc_principals

[kdc_principals]
princ1 = GeneralString:krbtgt
princ2 = GeneralString:FOOBAR.ORG

# ---- Root CA profile ----
[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, keyCertSign, cRLSign

[ user_cert ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, 1.3.6.1.4.1.311.20.2.2, 1.3.6.1.5.2.3.4
# clientAuth = TLS Web Client Authentication
# 1.3.6.1.4.1.311.20.2.2 = Smart Card Logon (Windows)
# 1.3.6.1.5.2.3.4 = id-pkinit-KPClientAuth (Kerberos client)
subjectAltName = @user_san
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
crlDistributionPoints = URI:https://ca.foobar.org/krb-ca.crl.pem

[ user_san ]
otherName.1 = 1.3.6.1.4.1.311.20.2.3;UTF8:${ENV::KRB5_PRINC}@FOOBAR.ORG
# This is the UPN mapping (Microsoft OID for User Principal Name)
otherName.2 = 1.3.6.1.5.2.2;SEQUENCE:krb5_princ

[ krb5_princ ]
realm = EXP:0,UTF8:FOOBAR.ORG
principalName = SEQUENCE:krb5_princ_seq

[ krb5_princ_seq ]
name-type = EXP:0,INTEGER:1 # 1 = KRB5-NT-PRINCIPAL
name-string = SEQUENCE:krb5_princ_names

[ krb5_princ_names ]
princ0 = UTF8:${ENV::KRB5_PRINC}

[ crl_ext ]
authorityKeyIdentifier = keyid:always

[sumit-bose]

Hi,

it looks it is about the string type. According to https://datatracker.ietf.org/doc/html/rfc4556 the id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3) is UTF-8 but for the strings in id-pkinit-san (1.3.6.1.5.2.2) there is a reference to https://datatracker.ietf.org/doc/html/rfc4120 where in general KerberosString is used which is defined as GeneralString.

So if you replace UTF8 in krb5_princ_names and krb5_princ with GeneralString and add EXP:1, to the sequences in krb5_princ and krb5_princ_seq as you did for the KDC principal, it should work.

Besides that, I will discuss with other developers if it would be ok to be a bit more relaxed and just ignored items which cannt be decoded or if it is better to error out.

HTH

bye,
Sumit

[MadCatX]

Huh, that was, indeed, the problem! An updated certificate and a bit of unrelated tweaking gets me through the login successfully. It is, perhaps, a bit unfortunate that the error message when there is unexpected data in the certificate is not more descriptive.

Anyway, thank you for your quick and very useful help, I very much appreciate that.