IKEv2 Has Two Signatures: Certificate and IKE_AUTH
The CA signs the certificate, and the peer signs its IKE_AUTH exchange with a scheme of its own. Read each from its own field, then record both.
Your ticket says the certificate is SHA-256 while the gateway log names a different signature algorithm, and somebody has already drafted a request to reissue the CA. Before that request goes anywhere, separate the two signatures: one is the issuer's stamp on a public key, the other is the peer proving it holds the matching private key during IKE_AUTH. Different components choose them, and they are allowed to differ. Reading each from the place it lives takes two commands and one table.
Read the issuer's signature from the certificate
The CA puts its signature on a binding between an identity and a key. That signature records what the CA did at issuance, not what the subject will do when it connects, so its algorithm describes the CA's own hash and key choice. A subject key of one type can sit under a CA key of another type without any inconsistency, and a CA key rotation is routine rather than a fault. Read the two fields and you have half the inventory:
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"Write both labels down as separate entries. The first describes the CA, the second describes the subject's key, and neither one predicts the online signature.
Read the online signature from the IKE exchange
During authentication each peer signs exchange data with its own private key, and the far side checks that proof against the certificate's identity, trust chain and policy. For RSA the padding and hash belong to this online scheme, so a longer key or a fresh SHA-256 certificate cannot by itself choose RSA-PSS for the authentication signature. The negotiated method shows up in the daemon's log or in its connection listing, never in the certificate. Ask each side what it negotiated, because the two directions can differ.
ipsec statusall | grep -i "auth\|proposal"When one side names a scheme the other cannot produce, you have found the mismatch the ticket was about. Reissuing the CA is the wrong repair for it, because the certificate was never what failed.
What RFC 7427 changes, and what it does not
The original methods are numbered per algorithm combination in RFC 7296. The later RFC 7427 signature extension adds a general Digital Signature method with signature-hash support signalling, so a new hash no longer needs a method number of its own. It is negotiated, not assumed: a peer does not gain the extension because its library can parse the same certificates, and a peer that implements only the original methods forces the gateway to keep one of them. That is a policy trade with a compatibility cost, not a defect.
Support is per direction and per connection, so test the build in front of you rather than trusting a family-level claim. A capability matrix written three years ago describes three-year-old builds.
Put four rows in the inventory
The record that ends the argument has four lines, each read from a different place and each changed by a different person. Fill it in before deciding anything, because the row that is wrong is what selects the fix.
| Object | Read it from | Changed by |
|---|---|---|
| certificate issuer signature | the certificate's Signature Algorithm field | the CA operator, at issuance |
| subject public key | the certificate's Public Key Algorithm field | whoever generates the subject key |
| IKE authentication scheme | daemon log or connection listing, auth and signature-hash notify | the IKE profile on both peers |
| IKE and ESP protection algorithms | the connection's proposal list | the IPsec profile, per direction |
Each row carries its own compatibility consequence. An ESP cipher change does not pick the issuer's signature, and loosening CA validation does not add an online method the peers never negotiated. When a ticket claims a signature mismatch, the row that is actually wrong is almost never the first one.
Decide the legacy case without weakening the PKI
An older peer may only offer a scheme your policy no longer permits. The choices are a time-boxed compatibility exception, a client update, or a different authentication arrangement for that peer alone. Rebuilding the PKI around a weaker certificate signature does not fix a limitation in the online exchange, and it weakens every other service that trusts the same CA. Record which row you changed and when the exception expires.
Then re-run the two reads from the top, because a change in one row can shift what negotiates in another. The whole inventory is two commands and one table, and it is the same work whether the peer is a router, a laptop or an appliance.