The server sends this message when it is satisfied with the clients security handshake and is ready to proceed with transmission/reception of the higher level protocols data. The SESSION-ID-DATA is used by the client and the server at this time to add entries to their respective session-identifier caches. The session-identifier caches must contain a copy of the MASTER-KEY sent in the CLIENT-MASTER-KEY message as the master key is used for all subsequent session key generation.
"N" is the number of bytes in the message that was sent, so "N-1" is the number of bytes in the SESSION-ID-DATA without the message header byte.
This message must be sent after the SERVER-VERIFY message.
REQUEST-CERTIFICATE (Phase 2; Sent encrypted)
char MSG-REQUEST-CERTIFICATE
char AUTHENTICATION-TYPE
char CERTIFICATE-CHALLENGE-DATA[N-2]
A server may issue this request at any time during the second phase of the connection handshake, asking for the client's certificate. The client responds with a CLIENT-CERTIFICATE message immediately if it has one, or an ERROR message (with error code NO-CERTIFICATE-ERROR) if it doesn't. The CERTIFICATE-CHALLENGE-DATA is a short byte string (whose length is greater than or equal to 16 bytes and less than or equal to 32 bytes) that the client will use to respond to this message.
The AUTHENTICATION-TYPE value is used to choose a particular means of authenticating the client. The following types are defined:
SSL_AT_MD5_WITH_RSA_ENCRYPTION
The SSL_AT_MD5_WITH_RSA_ENCRYPTION type requires that the client construct an MD5 message digest using information as described above in the section on the CLIENT-CERTIFICATE message. Once the digest is created, the client encrypts it using its private key (formatted according to the digital signature standard defined in PKCS#1). The server authenticates the client when it receives the CLIENT-CERTIFICATE message.
This message may be sent after a SERVER-VERIFY message and before a SERVER-FINISHED message.
2.7 Client/Server Protocol Messages
These messages are generated by both the client and the server.
ERROR (Sent clear or encrypted)
char MSG-ERROR
char ERROR-CODE-MSB
char ERROR-CODE-LSB
This message is sent when an error is detected. After the message is sent, the sending party shuts the connection down. The receiving party records the error and then shuts its connection down.
This message is sent in the clear if an error occurs during session key negotiation. After a session key has been agreed upon, errors are sent encrypted like all other messages.
Appendix A: ASN.1 Syntax For Certificates
Certificates are used by SSL to authenticate servers and clients. SSL Certificates are based largely on the X.509 [3] certificates. An X.509 certificate contains the following information (in ASN.1 [1] notation):
X.509-Certificate ::= SEQUENCE {
certificateInfo CertificateInfo,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING
}
CertificateInfo ::= SEQUENCE {
version [0] Version DEFAULT v1988,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo
}
Version ::= INTEGER { v1988(0) }
CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE {
notBefore UTCTime,
notAfter UTCTime
}
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY ALGORITHM OPTIONAL
}
For SSL's purposes we restrict the values of some of the X.509 fields:
The X.509-Certificate::signatureAlgorithm and CertificateInfo::signature fields must be identical in value.
The issuer name must resolve to a name that is deemed acceptable by the application using SSL. How the application using SSL does this is outside the scope of this memo.
Certificates are validated using a few straightforward steps. First, the signature on the certificate is checked and if invalid, the certificate is invalid (either a transmission error or an attempted forgery occurred). Next, the CertificateInfo::issuer field is verified to be an issuer that the application trusts (using an unspecified mechanism). The CertificateInfo::validity field is checked against the current date and verified.
Finally, the CertificateInfo::subject field is checked. This check is optional and depends on the level of trust required by the application using SSL.
Appendix B: Attribute Types and Object Identifiers
SSL uses a subset of the X.520 selected attribute types as well as a few specific object identifiers. Future revisions of the SSL protocol may include support for more attribute types and more object identifiers.
B.1 Selected attribute types
commonName { attributeType 3 }
The common name contained in the distinguished name contained within a certificate issuer or certificate subject.
countryName { attributeType 6 }
The country name contained in the distinguished name contained within a certificate issuer or certificate subject.
localityName { attributeType 7 }
The locality name contained in the distinguished name contained within a certificate issuer or certificate subject.
stateOrProvinceName { attributeType 8 }
The state or province name contained in the distinguished name contained within a certificate issuer or certificate subject.
organizationName { attributeType 10 }
The organization name contained in the distinguished name contained within a certificate issuer or certificate subject.
organizationalUnitName { attributeType 11 }
The organizational unit name contained in the distinguished name contained within a certificate issuer or certificate subject.
B.2 Object identifiers
md2withRSAEncryption { ... pkcs(1) 1 2 }
The object identifier for digital signatures that use both MD2 and RSA encryption. Used by SSL for certificate signature verification.
md5withRSAEncryption { ... pkcs(1) 1 4 }
The object identifier for digital signatures that use both MD5 and RSA encryption. Used by SSL for certificate signature verification.
rc4 { ... rsadsi(113549) 3 4 }
The RC4 symmetric stream cipher algorithm used by SSL for bulk encryption.
Appendix C: Protocol Constant Values
This section describes various protocol constants. A special value needs mentioning - the IANA reserved port number for "https" (HTTP using SSL). IANA has reserved port number 443 (decimal) for "https".
C.1 Protocol Version Codes
#define SSL_CLIENT_VERSION 0x0002
#define SSL_SERVER_VERSION 0x0002
C.2 Protocol Message Codes
The following values define the message codes that are used by version 2 of the SSL Handshake Protocol.
#define SSL_MT_ERROR 0
#define SSL_MT_CLIENT_HELLO 1
#define SSL_MT_CLIENT_MASTER_KEY 2
#define SSL_MT_CLIENT_FINISHED 3
#define SSL_MT_SERVER_HELLO 4
#define SSL_MT_SERVER_VERIFY 5
#define SSL_MT_SERVER_FINISHED 6
#define SSL_MT_REQUEST_CERTIFICATE 7
#define SSL_MT_CLIENT_CERTIFICATE 8
C.3 Error Message Codes
The following values define the error codes used by the ERROR message.
#define SSL_PE_NO_CIPHER 0x0001
#define SSL_PE_NO_CERTIFICATE 0x0002
#define SSL_PE_BAD_CERTIFICATE 0x0004
#define SSL_PE_UNSUPPORTED_CERTIFICATE_TYPE 0x0006
C.4 Cipher Kind Values
The following values define the CIPHER-KIND codes used in the CLIENT-HELLO and SERVER-HELLO messages.
#define SSL_CK_RC4_128_WITH_MD5 0x01,0x00,0x80
#define SSL_CK_RC4_128_EXPORT40_WITH_MD5 0x02,0x00,0x80
#define SSL_CK_RC2_128_CBC_WITH_MD5 0x03,0x00,0x80
#define SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5 0x04,0x00,0x80
#define SSL_CK_IDEA_128_CBC_WITH_MD5 0x05,0x00,0x80
#define SSL_CK_DES_64_CBC_WITH_MD5 0x06,0x00,0x40
#define SSL_CK_DES_192_EDE3_CBC_WITH_MD5 0x07,0x00,0xC0
