diff options
Diffstat (limited to 'secure/lib/libcrypto/man/man7/ossl-guide-tls-introduction.7')
| -rw-r--r-- | secure/lib/libcrypto/man/man7/ossl-guide-tls-introduction.7 | 27 |
1 files changed, 15 insertions, 12 deletions
diff --git a/secure/lib/libcrypto/man/man7/ossl-guide-tls-introduction.7 b/secure/lib/libcrypto/man/man7/ossl-guide-tls-introduction.7 index 3c3000ea0020..67057790a36d 100644 --- a/secure/lib/libcrypto/man/man7/ossl-guide-tls-introduction.7 +++ b/secure/lib/libcrypto/man/man7/ossl-guide-tls-introduction.7 @@ -1,5 +1,5 @@ .\" -*- mode: troff; coding: utf-8 -*- -.\" Automatically generated by Pod::Man 5.0102 (Pod::Simple 3.45) +.\" Automatically generated by Pod::Man v6.0.2 (Pod::Simple 3.45) .\" .\" Standard preamble: .\" ======================================================================== @@ -52,10 +52,13 @@ . \} .\} .rr rF +.\" +.\" Required to disable full justification in groff 1.23.0. +.if n .ds AD l .\" ======================================================================== .\" .IX Title "OSSL-GUIDE-TLS-INTRODUCTION 7ossl" -.TH OSSL-GUIDE-TLS-INTRODUCTION 7ossl 2025-09-30 3.5.4 OpenSSL +.TH OSSL-GUIDE-TLS-INTRODUCTION 7ossl 2026-04-07 3.5.6 OpenSSL .\" For nroff, turn off justification. Always turn off hyphenation; it makes .\" way too many mistakes in technical documents. .if n .ad l @@ -78,7 +81,7 @@ the information exchanged to prevent an attacker from changing it. Finally it provides authentication so that one or both parties can be sure that they are talking to who they think they are talking to and not some imposter. .PP -Sometimes TLS is referred to by its predecessor's name SSL (Secure Sockets +Sometimes TLS is referred to by its predecessor\*(Aqs name SSL (Secure Sockets Layer). OpenSSL dates from a time when the SSL name was still in common use and hence many of the functions and names used by OpenSSL contain the "SSL" abbreviation. Nonetheless OpenSSL contains a fully fledged TLS implementation. @@ -120,7 +123,7 @@ susceptible to security problems. OpenSSL does not support SSLv2 (it was removed in OpenSSL 1.1.0). Support for SSLv3 is available as a compile time option \- but it is not built by default. Support for TLSv1.0, TLSv1.1, TLSv1.2 and TLSv1.3 are all available by default -in a standard build of OpenSSL. However special run-time configuration is +in a standard build of OpenSSL. However special run\-time configuration is required in order to make TLSv1.0 and TLSv1.1 work successfully. .PP OpenSSL will always try to negotiate the highest protocol version that it has @@ -134,7 +137,7 @@ the server that it claims to be and not some imposter. In order to do this the server will send to the client a digital certificate (also commonly referred to as an X.509 certificate). The certificate contains various information about the server including its full DNS hostname. Also within the certificate is the -server's public key. The server operator will have a private key which is +server\*(Aqs public key. The server operator will have a private key which is linked to the public key and must not be published. .PP Along with the certificate the server will also send to the client proof that it @@ -146,13 +149,13 @@ possession of the correct private key. .PP The certificate that the server sends will also be signed by a Certificate Authority. The Certificate Authority (commonly known as a CA) is a third party -organisation that is responsible for verifying the information in the server's +organisation that is responsible for verifying the information in the server\*(Aqs certificate (including its DNS hostname). The CA should only sign the certificate if it has been able to confirm that the server operator does indeed have control of the server associated with its DNS hostname and that the server operator has control of the private key. .PP -In this way, if the client trusts the CA that has signed the server's +In this way, if the client trusts the CA that has signed the server\*(Aqs certificate and it can verify that the server has the right private key then it can trust that the server truly does represent the DNS hostname given in the certificate. The client must also verify that the hostname given in the @@ -165,7 +168,7 @@ of CAs that the client trusts as well as the DNS hostname for the server that this client is trying to connect to. .PP Note that it is common for certificates to be built up into a chain. For example -a server's certificate may be signed by a key owned by a an intermediate CA. +a server\*(Aqs certificate may be signed by a key owned by a an intermediate CA. That intermediate CA also has a certificate containing its public key which is in turn signed by a key owned by a root CA. The client may only trust the root CA, but if the server sends both its own certificate and the certificate for the @@ -221,7 +224,7 @@ directly in \fBOPENSSLDIR\fR. For example if \fBOPENSSLDIR\fR is "/usr/local/ssl then save it as "/usr/local/ssl/cert.pem". .PP You can also use environment variables to override the default location that -OpenSSL will look for its trusted certificate store. Set the \fBSSL_CERT_PATH\fR +OpenSSL will look for its trusted certificate store. Set the \fBSSL_CERT_DIR\fR environment variable to give the directory where OpenSSL should looks for its certificates or the \fBSSL_CERT_FILE\fR environment variable to give the name of a single file containing all of the certificates. See \fBopenssl\-env\fR\|(7) for @@ -326,7 +329,7 @@ server always sends its Finished message before the client. The client later responds with its Finished message. At this point the client has completed the handshake because it has both sent and received a Finished message. The server has sent its Finished message but the Finished message from the client may still -be in-flight, so the server is still in the handshake phase. It is even possible +be in\-flight, so the server is still in the handshake phase. It is even possible that the server will fail to complete the handshake (if it considers there is some problem with the messages sent from the client), even though the client may have already progressed to sending application data. In TLSv1.2 this can happen @@ -336,7 +339,7 @@ second. Once the handshake is complete the application data transfer phase begins. Strictly speaking there are some situations where the client can start sending application data even earlier (using the TLSv1.3 "early data" capability) \- but -we're going to skip over that for this basic introduction. +we\*(Aqre going to skip over that for this basic introduction. .PP During application data transfer the client and server can read and write data to the connection freely. The details of this are typically left to some higher @@ -368,7 +371,7 @@ See \fBossl\-guide\-quic\-introduction\fR\|(7) for an introduction to QUIC in Op \&\fBossl\-guide\-tls\-server\-block\fR\|(7), \fBossl\-guide\-quic\-introduction\fR\|(7) .SH COPYRIGHT .IX Header "COPYRIGHT" -Copyright 2023\-2025 The OpenSSL Project Authors. All Rights Reserved. +Copyright 2023\-2026 The OpenSSL Project Authors. All Rights Reserved. .PP Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy |