Hello Team,

due to the newest version requirements of Google and Apple (note here) we had to add to our certificates a DNS in Subject Alternative name (SAN) which is identical to the Common Name (CN), because DNS names in the CN of a certificate are no longer trusted.
This change got a negative sideffect to our OIDC JWKS endpoint, because there are duplicate kid entries at the moment.
Some of our OIDC clients need these entries in an unique way, so they are not able to handle duplicate entries for the signature check.
Do you have any ideas for solving this issue? Also we are not sure if this is an ISAM problem or it must be fixed on the relying parties side.

Thanks & best regards
Thomas

Hello Thomas,

Duplicate KIDS can happen when you have multiple certificates with the same subjectDN and serial numbers but different validity dates in your configured keystore.

My recommendation is to remove the certificates you are not using and that should resolve the issue.
The KID value is loosely based on the subject DN, but having multiple certificates with the same DN and different Serial Numbers is totally legal and generates different KIDs.

Having multiple KIDs, though, causes issues.

Hello Team,

due to the newest version requirements of Google and Apple (note here) we had to add to our certificates a DNS in Subject Alternative name (SAN) which is identical to the Common Name (CN), because DNS names in the CN of a certificate are no longer trusted.
This change got a negative sideffect to our OIDC JWKS endpoint, because there are duplicate kid entries at the moment.
Some of our OIDC clients need these entries in an unique way, so they are not able to handle duplicate entries for the signature check.
Do you have any ideas for solving this issue? Also we are not sure if this is an ISAM problem or it must be fixed on the relying parties side.

Thanks & best regards
Thomas

Hello Jack, 

but we have one certificate with one serial number which contains the same DNS for CN and SAN. In our JWKS endpoint this certificate will be interpreted as two duplicate kid entries because of the same DNS in CN and SAN. Unfortunately we have to set the same DNS name in SAN  because of the newest certificate restrictions from Google and Apple that DNS names in the CN of a certificate are no longer trusted therefore you need to set this DNS name in SAN as well for getting a trusted connection (see abovementioned note).
We are not sure if this new requirement is related to an ISAM problem or it must be fixed on OIDC parties side? But I also agree with you having multiple KIDs causes issues.

Thanks for your answer & best regards
Thomas

Hello Thomas,

Duplicate KIDS can happen when you have multiple certificates with the same subjectDN and serial numbers but different validity dates in your configured keystore.

My recommendation is to remove the certificates you are not using and that should resolve the issue.
The KID value is loosely based on the subject DN, but having multiple certificates with the same DN and different Serial Numbers is totally legal and generates different KIDs.

Having multiple KIDs, though, causes issues.

Hello Team,

due to the newest version requirements of Google and Apple (note here) we had to add to our certificates a DNS in Subject Alternative name (SAN) which is identical to the Common Name (CN), because DNS names in the CN of a certificate are no longer trusted.
This change got a negative sideffect to our OIDC JWKS endpoint, because there are duplicate kid entries at the moment.
Some of our OIDC clients need these entries in an unique way, so they are not able to handle duplicate entries for the signature check.
Do you have any ideas for solving this issue? Also we are not sure if this is an ISAM problem or it must be fixed on the relying parties side.

Thanks & best regards
Thomas