IdP Signing Certificate question

[Nate Klingenstein]

Brian,

The copy of metadata that you have is of no relevance to the SP's.  They only care about the copy of the metadata that they have.  So, placing another certificate in a distinct copy of metadata won't affect anything on SP's that don't have that distinct copy.  If they're pulling the new copy automatically and parsing everything down to the certificate validity as soon as they get it, they could conceivably blow up then, but that would strike me as unlikely.

The defaults in keygen.sh seem reasonable:

[root at ip-172-31-3-67 bin]# ./keygen.sh --help
Usage: SelfSignedCertificateGenerator [options]
  Options:
    --certAlg
      Certificate algorithm (default: SHA256withRSA)
      Default: SHA256withRSA
    --certfile
      Path to certificate file
    --dnsAltName
      DNS subjectAltNames for certificate
    --help
      Display program usage
  * --hostname
      Hostname for certificate subject
    --keyfile
      Path to private key file
    --lifetime
      Certificate lifetime in years (default: 20)
      Default: 20
    --size
      Size of key to generate (default: 3072)
      Default: 3072

SHA-512 could cause interoperability issues with some SP's, but they ought to advertise the algorithms they support in their metadata.  Of course, one that doesn't support SHA-512 is unlikely to have gone to the trouble of noting that, so it's going to be trial and error.  I would expect no problems from the key length.

The moment the hammer really drops is when you switch your IdP's signing key, not when you change your metadata, so I would hop on the keypair(if desired) and certificate generation and metadata distribution immediately and get ready for a ride.

Good luck,
Nate.

--------
Signet, Inc.
The Art of Access ®

https://www.signet.id

-----Original message-----
From: Brian Biggs
Sent: Thursday, January 21 2021, 9:41 am
To: Shib Users
Subject: IdP Signing Certificate question

Hi,

I have finally reached the bottom of the rabbit hole. I have inherited an IdP that is using a signing cert that was signed by our (very old) internal CA cert that contains an MD5 signature algorithm. This is causing problems with some of our SPs who are trying to validate the cert. I have been unable to convince said SPs that they do not need to validate.

So, my question is: If I generate a new self-signed IdP signing cert using the existing IdP signing key, then drop that new cert into our metadata, will SPs who have the old metadata continue to work? Obviously we'd be distributing the new metadata to our SPs as quickly as possible, but the process will take some time.

Follow up question: Is there a "best practice" for what key length and digest hashing algorithm to use for an IdP signing cert? I'm guessing 2048 and sha256 are the minimum, but will going to 4096 and sha512 likely cause interoperability issues with some SPs?

Thank you in advance,

-Brian

--

For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg

To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net