1=pod 2 3=head1 NAME 4 5SSL_CTX_set_tlsext_status_cb, SSL_CTX_set_tlsext_status_arg, 6SSL_set_tlsext_status_type, SSL_get_tlsext_status_ocsp_resp, 7SSL_set_tlsext_status_ocsp_resp - OCSP Certificate Status Request functions 8 9=head1 SYNOPSIS 10 11 #include <openssl/tls1.h> 12 13 long SSL_CTX_set_tlsext_status_cb(SSL_CTX *ctx, 14 int (*callback)(SSL *, void *)); 15 long SSL_CTX_set_tlsext_status_arg(SSL_CTX *ctx, void *arg); 16 17 long SSL_set_tlsext_status_type(SSL *s, int type); 18 19 long SSL_get_tlsext_status_ocsp_resp(ssl, unsigned char **resp); 20 long SSL_set_tlsext_status_ocsp_resp(ssl, unsigned char *resp, int len); 21 22=head1 DESCRIPTION 23 24A client application may request that a server send back an OCSP status response 25(also known as OCSP stapling). To do so the client should call the 26SSL_set_tlsext_status_type() function prior to the start of the handshake. 27Currently the only supported type is B<TLSEXT_STATUSTYPE_ocsp>. This value 28should be passed in the B<type> argument. The client should additionally provide 29a callback function to decide what to do with the returned OCSP response by 30calling SSL_CTX_set_tlsext_status_cb(). The callback function should determine 31whether the returned OCSP response is acceptable or not. The callback will be 32passed as an argument the value previously set via a call to 33SSL_CTX_set_tlsext_status_arg(). Note that the callback will not be called in 34the event of a handshake where session resumption occurs (because there are no 35Certificates exchanged in such a handshake). 36 37The response returned by the server can be obtained via a call to 38SSL_get_tlsext_status_ocsp_resp(). The value B<*resp> will be updated to point 39to the OCSP response data and the return value will be the length of that data. 40Typically a callback would obtain an OCSP_RESPONSE object from this data via a 41call to the d2i_OCSP_RESPONSE() function. If the server has not provided any 42response data then B<*resp> will be NULL and the return value from 43SSL_get_tlsext_status_ocsp_resp() will be -1. 44 45A server application must also call the SSL_CTX_set_tlsext_status_cb() function 46if it wants to be able to provide clients with OCSP Certificate Status 47responses. Typically the server callback would obtain the server certificate 48that is being sent back to the client via a call to SSL_get_certificate(); 49obtain the OCSP response to be sent back; and then set that response data by 50calling SSL_set_tlsext_status_ocsp_resp(). A pointer to the response data should 51be provided in the B<resp> argument, and the length of that data should be in 52the B<len> argument. 53 54=head1 RETURN VALUES 55 56The callback when used on the client side should return a negative value on 57error; 0 if the response is not acceptable (in which case the handshake will 58fail) or a positive value if it is acceptable. 59 60The callback when used on the server side should return with either 61SSL_TLSEXT_ERR_OK (meaning that the OCSP response that has been set should be 62returned), SSL_TLSEXT_ERR_NOACK (meaning that an OCSP response should not be 63returned) or SSL_TLSEXT_ERR_ALERT_FATAL (meaning that a fatal error has 64occurred). 65 66SSL_CTX_set_tlsext_status_cb(), SSL_CTX_set_tlsext_status_arg(), 67SSL_set_tlsext_status_type() and SSL_set_tlsext_status_ocsp_resp() return 0 on 68error or 1 on success. 69 70SSL_get_tlsext_status_ocsp_resp() returns the length of the OCSP response data 71or -1 if there is no OCSP response data. 72 73=cut 74