on page \pageref{sec:x509api}. Some examples are listed below.
-\subsection{Verifying an X.509 certificate}
+
+\subsection{X.509 certificates}
+An X.509 certificate usually contains information about the certificate
+holder, the signer, a unique serial number, expiration dates etc. Some
+functions of \gnutls{}' API for certificate parsing are:
+\begin{itemize}
+\item \printfunc{gnutls_x509_crt_init}{gnutls\_x509\_crt\_init}
+\item \printfunc{gnutls_x509_crt_import}{gnutls\_x509\_crt\_import}
+\item \printfunc{gnutls_x509_crt_get_dn}{gnutls\_x509\_crt\_get\_dn}
+\item \printfunc{gnutls_x509_crt_get_serial}{gnutls\_x509\_crt\_get\_serial}
+\item \printfunc{gnutls_x509_crt_get_subject_alt_name}{gnutls\_x509\_crt\_get\_subject\_alt\_name}
+\end{itemize}
+
+\par
+An example program that reads the peer's certificate,
+and prints some information about the peer's certificate in a TLS session,
+is listed below.
+
+\input{ex-x509-info}
+
+
+\subsection{Verifying X.509 certificate paths}
Verifying certificate\index{Verifying certificate paths} paths is important
in X.509 authentication. For this purpose the function
\printfunc{gnutls_x509_crt_verify}{gnutls\_x509\_crt\_verify} is provided. The
owner is the one you expect. See section \ref{ex:rfc2818} on page \pageref{ex:rfc2818},
for an example.
-\par
-Client certificate authentication\index{Certificate authentication!Client} is
-optional in \tls{}. A server may request a certificate from the client -- using the
-\printfunc{gnutls_certificate_server_set_request}{gnutls\_certificate\_server\_set\_request}
-function. If a certificate is to be requested by the client, at the handshake
-procedure, the server will send an extra packet,
-than contains a list of acceptable certificate signers, and indicates the
-request of a certificate. The client may then send a certificate, signed
-by one of the server's acceptable signers. In \gnutls{} the server's acceptable
-signers list is constructed using the trusted CA certificates in the
-credentials structure.
-
-\section{Using X.509\index{X.509 certificates} certificates and other structures}
-
-\subsection{Parsing an X.509 certificate}
-An X.509 certificate usually contains information about the certificate
-holder, the signer, a unique serial number, expiration dates etc. Some
-function of the \gnutls{} API for certificate parsing are:
-\begin{itemize}
-\item \printfunc{gnutls_x509_crt_init}{gnutls\_x509\_crt\_init}
-\item \printfunc{gnutls_x509_crt_import}{gnutls\_x509\_crt\_import}
-\item \printfunc{gnutls_x509_crt_get_dn}{gnutls\_x509\_crt\_get\_dn}
-\item \printfunc{gnutls_x509_crt_get_serial}{gnutls\_x509\_crt\_get\_serial}
-\item \printfunc{gnutls_x509_crt_get_subject_alt_name}{gnutls\_x509\_crt\_get\_subject\_alt\_name}
-\end{itemize}
-
-\par
-An example is shown below, that reads the peer's certificate,
-and prints some information about the peer's certificate in a TLS session.
-
-\input{ex-x509-info}
-\subsection{Using certificate requests}
+\subsection{PKCS \#10 certificate requests}
A certificate request is a structure, defined in PKCS \#10, which
is contains information about an applicant of a certificate service.
It usually contains a private key, a distinguished name and secondary
\input{ex-crq}
-\subsection{Using PKCS \#12 structures}
+\subsection{PKCS \#12 structures}
A PKCS \#12 structure usually contains a user's private keys and
certificates. It is commonly used in browsers to export and import
the user's identities.
const int protocol_priority[] = { GNUTLS_TLS1, GNUTLS_SSL3, 0 };
const int kx_priority[] = { GNUTLS_KX_RSA, GNUTLS_KX_DHE_RSA, 0 };
-const int cipher_priority[] = { GNUTLS_CIPHER_3DES_CBC, GNUTLS_CIPHER_ARCFOUR_128, 0};
+const int cipher_priority[] = { GNUTLS_CIPHER_3DES_CBC,
+ GNUTLS_CIPHER_ARCFOUR_128, 0};
const int comp_priority[] = { GNUTLS_COMP_NULL, 0 };
const int mac_priority[] = { GNUTLS_MAC_SHA, GNUTLS_MAC_MD5, 0 };
return session;
}
-gnutls_dh_params dh_params;
+static gnutls_dh_params dh_params;
static int generate_dh_params(void) {
/* Generate Diffie Hellman parameters - for use with DHE
* kx algorithms. These should be discarded and regenerated
- * once a day, once a week or once a month. Depends on the
+ * once a day, once a week or once a month. Depending on the
* security requirements.
*/
gnutls_dh_params_init( &dh_params);
gnutls_session session;
char buffer[MAX_BUF + 1];
int optval = 1;
- char name[256];
-
- strcpy(name, "Echo Server");
/* this must be called once in the program
*/
err = listen(listen_sd, 1024);
SOCKET_ERR(err, "listen");
- printf("%s ready. Listening to port '%d'.\n\n", name, PORT);
+ printf("Server ready. Listening to port '%d'.\n\n", PORT);
client_len = sizeof(sa_cli);
for (;;) {
\input{ciphersuites}
+\subsection{Client authentication}
+In the case of ciphersuites that use certificate authentication, the
+authentication\index{Certificate authentication!Client} of the client is
+optional in \tls{}. A server may request a certificate from the client -- using the
+\printfunc{gnutls_certificate_server_set_request}{gnutls\_certificate\_server\_set\_request}
+function. If a certificate is to be requested by the client, at the handshake
+procedure, the server will send an extra packet,
+than contains a list of acceptable certificate signers, and indicates the
+request of a certificate. The client may then send a certificate, signed
+by one of the server's acceptable signers. In \gnutls{} the server's acceptable
+signers list is constructed using the trusted CA certificates in the
+credentials structure.
+
\subsection{Resuming Sessions\index{Resuming sessions}}
\label{resume}
\par
projects / thirdparty / gnutls.git / commitdiff
