EMSA-PSS (RFC 8017 §9.1) hashes M' = 0x00×8 ‖ mHash ‖ salt to H, builds DB = PS ‖ 0x01 ‖ salt, masks it with MGF1(H) and outputs maskedDB ‖ H ‖ 0xbc, which is then exponentiated like any RSA signature. The parameters are the hash, the mask generation function (MGF1 with its own hash), the salt length and the trailer field, and signer and verifier must agree on all of them.
Salt length is the classic interop failure. JOSE PS256/PS384/PS512 fix MGF1 to the same hash and the salt length to the hash length (RFC 7518 §3.5), and FIPS 186-5 §5.4(g) requires 0 ≤ sLen ≤ hLen. OpenSSL 1.1.1 and 3.0 signed with the maximum salt by default (222 bytes for RSA-2048 with SHA-256), while OpenSSL 3.1 and later default to auto-digestmax, which in practice equals the digest length; a verifier that pins a different length rejects the signature with salt length check failed.
TLS 1.3 requires PSS whenever RSA signs handshake data: rsa_pss_rsae_sha256 (0x0804) uses an ordinary rsaEncryption key and rsa_pss_pss_sha256 (0x0809) a key restricted to PSS by the id-RSASSA-PSS OID 1.2.840.113549.1.1.10 (RFC 4055). PKCS #1 v1.5 survives only in certificate signatures. Keys are interchangeable with PKCS #1 v1.5: switching an RS256 deployment to PS256 needs no new key, only verifiers that accept PSS.