What does it mean to "sign with a certificate"?

Question

As part of the SSL handshake, the server responds to the browser with 2 things -

1. The server's public key
2. Some metadata, like what version of SSL is being used, the cipher algorithm being used, etc...

All of this is "signed" by a certificate so the browser can verify the above items came from the server.

1. What does "signing" mean here? Is the whole bundle above encrypted using another server private key, to which the CA has the public key? Or is it just a message tacked on at the end that says something like "check with Verisign that I'm legitimate" ?

2. When the browser receives the package above and verifies the certificate, it generates a symmetric key that it sends back to the server. All further communication will take place using this symmetric key. What is this key? Is this again a newly generated public/private keypair, or is it something else?

Thanks!

EDIT: Great answer from CBHacking on the 2nd question. To elaborate on the first, I found the following example of a certificate a browser might receive from here.

I can see that the certificate includes the server's public key and a hashed message encrypted with the server's private key at the bottom. I'm guessing the browser checks the hashed messages - but what is the message being hashed exactly? And what's the blob after --BEGIN CERTIFICATE-- ?

    Certificate: 
        Data: 
            Version: 3 (0x2) 
            Serial Number: 1 (0x1) 
            Signature Algorithm: md5WithRSAEncryption 
            Issuer: C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root CA/Email=administrator@sopac.org 
            Validity 
                Not Before: Nov 20 05:47:44 2001 GMT 
                Not After : Nov 20 05:47:44 2002 GMT 
            Subject: C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=www.sopac.org/Email=administrator@sopac.org 
            Subject Public Key Info: 
                Public Key Algorithm: rsaEncryption  
                RSA Public Key: (1024 bit) 
                    Modulus (1024 bit): 
                        00:ba:54:2c:ab:88:74:aa:6b:35:a5:a9:c1:d0:5a: 
                        9b:fb:6b:b5:71:bc:ef:d3:ab:15:cc:5b:75:73:36: 
                        b8:01:d1:59:3f:c1:88:c0:33:91:04:f1:bf:1a:b4: 
                        7a:c8:39:c2:89:1f:87:0f:91:19:81:09:46:0c:86: 
                        08:d8:75:c4:6f:5a:98:4a:f9:f8:f7:38:24:fc:bd: 
                        94:24:37:ab:f1:1c:d8:91:ee:fb:1b:9f:88:ba:25: 
                        da:f6:21:7f:04:32:35:17:3d:36:1c:fb:b7:32:9e: 
                        42:af:77:b6:25:1c:59:69:af:be:00:a1:f8:b0:1a: 
                        6c:14:e2:ae:62:e7:6b:30:e9 
                    Exponent: 65537 (0x10001) 
             X509v3 extensions: 
                 X509v3 Basic Constraints: 
                     CA:FALSE 
                 Netscape Comment: 
                     OpenSSL Generated Certificate
                 X509v3 Subject Key Identifier:
                     FE:04:46:ED:A0:15:BE:C1:4B:59:03:F8:2D:0D:ED:2A:E0:ED:F9:2F 
                 X509v3 Authority Key Identifier:
                     keyid:E6:12:7C:3D:A1:02:E5:BA:1F:DA:9E:37:BE:E3:45:3E:9B:AE:E5:A6 
                     DirName:/C=FJ/ST=Fiji/L=Suva/O=SOPAC/OU=ICT/CN=SOPAC Root CA/Email=administrator@sopac.org 
                     serial:00
        Signature Algorithm: md5WithRSAEncryption
            34:8d:fb:65:0b:85:5b:e2:44:09:f0:55:31:3b:29:2b:f4:fd: 
            aa:5f:db:b8:11:1a:c6:ab:33:67:59:c1:04:de:34:df:08:57: 
            2e:c6:60:dc:f7:d4:e2:f1:73:97:57:23:50:02:63:fc:78:96: 
            34:b3:ca:c4:1b:c5:4c:c8:16:69:bb:9c:4a:7e:00:19:48:62: 
            e2:51:ab:3a:fa:fd:88:cd:e0:9d:ef:67:50:da:fe:4b:13:c5: 
            0c:8c:fc:ad:6e:b5:ee:40:e3:fd:34:10:9f:ad:34:bd:db:06: 
            ed:09:3d:f2:a6:81:22:63:16:dc:ae:33:0c:70:fd:0a:6c:af:
            bc:5a 
    -----BEGIN CERTIFICATE----- 
    MIIDoTCCAwqgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBiTELMAkGA1UEBhMCRkox 
    DTALBgNVBAgTBEZpamkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQww 
    CgYDVQQLEwNJQ1QxFjAUBgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0B 
    CQEWF2FkbWluaXN0cmF0b3JAc29wYWMub3JnMB4XDTAxMTEyMDA1NDc0NFoXDTAy 
    MTEyMDA1NDc0NFowgYkxCzAJBgNVBAYTAkZKMQ0wCwYDVQQIEwRGaWppMQ0wCwYD 
    VQQHEwRTdXZhMQ4wDAYDVQQKEwVTT1BBQzEMMAoGA1UECxMDSUNUMRYwFAYDVQQD 
    Ew13d3cuc29wYWMub3JnMSYwJAYJKoZIhvcNAQkBFhdhZG1pbmlzdHJhdG9yQHNv 
    cGFjLm9yZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAulQsq4h0qms1panB 
    0Fqb+2u1cbzv06sVzFt1cza4AdFZP8GIwDORBPG/GrR6yDnCiR+HD5EZgQlGDIYI 
    2HXEb1qYSvn49zgk/L2UJDer8RzYke77G5+IuiXa9iF/BDI1Fz02HPu3Mp5Cr3e2 
    JRxZaa++AKH4sBpsFOKuYudrMOkCAwEAAaOCARUwggERMAkGA1UdEwQCMAAwLAYJ 
    YIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1Ud
    DgQWBBT+BEbtoBW+wUtZA/gtDe0q4O35LzCBtgYDVR0jBIGuMIGrgBTmEnw9oQLl 
    uh/anje+40U+m67lpqGBj6SBjDCBiTELMAkGA1UEBhMCRkoxDTALBgNVBAgTBEZp 
    amkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQwwCgYDVQQLEwNJQ1Qx 
    FjAUBgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0BCQEWF2FkbWluaXN0 
    cmF0b3JAc29wYWMub3JnggEAMA0GCSqGSIb3DQEBBAUAA4GBADSN+2ULhVviRAnw 
    VTE7KSv0/apf27gRGsarM2dZwQTeNN8IVy7GYNz31OLxc5dXI1ACY/x4ljSzysQb 
    xUzIFmm7nEp+ABlIYuJRqzr6/YjN4J3vZ1Da/ksTxQyM/K1ute5A4/00EJ+tNL3b 
    Bu0JPfKmgSJjFtyuMwxw/Qpsr7xa
    -----END CERTIFICATE-----

Answer 1

Technically, it's a misnomer to say the data is "signed with the certificate", but it's close enough. Digital signatures are created using a private key. A certificate contains a corresponding public key that can be used to verify that the signature is valid. Basically, the signature says "somebody who knows a private key has verified that this data is as they want it to be" and the certificate says "this signature was made by Server XYZ so that means Server XYZ knows the private key that corresponds the public key in this certificate."

Certificates contain a number of pieces of data, as you showed in your edit. The most important pieces are these:

• The Subject Public Key. This is an asymmetric key part that can be used to encrypt stuff you send to the subject (server, in this case), or to verify stuff that the subject has signed.
• The Subject Name. This identifies the subject (by host/domain name, in this case).
• The Signature, usually from a certificate authority (CA). It is made by taking a cryptographic hash of the certificate data (aside from the signature, obviously) and signing that hash with the CA's private key. This tells the reader of the certificate "I, the certificate authority, vouch that this Subject uses this Public Key, and you can verify it by checking that this Signature verifies with my public key." Browsers (and other programs) have a pre-loaded list of CA certificates (which include public keys) that they trust. By the way, that certificate example you added has an MD5-based signature, which means it cannot be trusted. MD5 is considered broken for signature purposes.

To answer your edited-in question, that -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- blob of Base64 is the actual certificate. The data above that is pulled out of the blob and decoded.

For your second question, the bulk encryption key is a symmetric key (as you said), so it can't be a public/private key pair, because those are asymmetric keys (one is used for encryption, the other for decryption). The symmetric key is used for algorithms like AES, 3DES, or RC4 (please don't use either of the latter in TLS!). These algorithms are much, much faster than asymmetric cryptographic functions like RSA. The symmetric key can be communicated using asymmetric encryption, because the key itself isn't too big, but all future communication has to use the symmetric key or it would take far too long.