The exact signature scheme depends on the protocol version; however, in all cases, it relates to what Crypto++ calls "signature schemes with appendix".
PKCS#1 describes two signature schemes (and two asymmetric encryption schemes, which are not relevant here): the "old one" (called "v1.5") and the "new one" (called "PSS"). SSL/TLS relies on the old one (v1.5).
In PKCS#1 v1.5 signature generation, the following occurs:
The data which is to be signed is hashed, with some hash function. Let's call x the resulting sequence of bytes. E.g., if the hash function is SHA-256, then the length of x is 256 bits, i.e. 32 bytes.
A header t is added to x. The header is a fixed sequence of bytes that identifies the hash function (technically, x is used as parameter in a DER-encoded ASN.1 structure that also identifies the hash function with an OID; however, it is simpler to think of it as a fixed header).
Some bytes are added before the concatenation of t and x, so as to obtain the following structure:
00 01 FF FF ... FF 00 t x
That is, a byte of value 0, then a byte of value 1, then some bytes of value FF, then a byte of value 0, then t, then x, are concatenated in that order. The number of "FF" bytes is adjusted so that the total length is exactly the length, in bytes, of the RSA modulus (i.e. 256 bytes for a 2048-bit RSA key). This step is called "PKCS#1 type 1 padding".
The padded string is then interpreted as a big integer (using big-endian convention), which then goes into the modular exponentiation that is at the core of the RSA signature scheme.
With TLS-1.2, the signature scheme must be exactly the one above, with a hash function that depends on what the client and server support. With the Signature Algorithms extension, the client specifies in its
ClientHello message what kinds of hash functions it can use with the RSA algorithm; if that extension is lacking then the server must assume that the client supports SHA-1. The value of the t header is given explicitly, for the most common hash function, in section 9.2 of PKCS#1.
In previous TLS versions (SSL-3.0, TLS-1.0 and TLS-1.1), the scheme is subtly different: the t header is empty, and x is the concatenation of the MD5 and the SHA-1 hashes of what is to be signed. Thus, the length of t is 0, and the length of x is 36 bytes (16 bytes for the MD5, 20 bytes for the SHA-1). There is no discussion between client and server about which hash functions to use; it is always MD5+SHA-1.
A cursory look at the manual seems to indicate that at least "normal" signatures (for TLS-1.2) can be computed with Crypto++ using
RSASS<PKCS1v15, H> where
H will be
SHA256... I do not know if Crypto++ includes code for the older scheme where the hash is the concatenation of MD5 and SHA-1, and there is no header.