Re: namespacing in mod_ssl
On Apr 20, 2015 2:32 AM, "Joe Orton" wrote: > > On Thu, Apr 16, 2015 at 06:42:04AM +0200, Kaspar Brand wrote: > > On 15.04.2015 18:36, Stefan Sperling wrote: > > > However, the actual issue here is that mod_ssl is squatting the SSL_ namespace. > > > Historically this may have made sense (it seems mod_ssl and OpenSSL have > > > shared history/authors). Bill Rowe suggested to try moving mod_ssl's > > > functions into the ap_ namespace to avoid such clashes in the future. > > > > Agreed that mod_ssl should avoid stepping into the SSL_* yard. As > > pointed out by Jeff, ap_* is fairly foreign in the mod_ssl case, though, > > and my preference is for s/SSL_/ssl_/ for functions and > > s/SSL_/MODSSL_/ for constants (in the latter case, there's actually > > quite some more stuff lurking - SSL_OPT_*, SSL_PROTOCOL_* etc.). > > It would be safer to go with a "modssl_" prefix for functions too, I've > sometimes tried to use that for new things though probably not > consistently. OpenSSL's libssl.so does export symbols using the "ssl_" > prefix, though they are probably all internal things which shouldn't be > global. I concur, but can we quit playing fetch me a rock? modssl_*() namespace? Final answer? +1 here to either ssl_ or modssl_
Re: namespacing in mod_ssl
On Thu, Apr 16, 2015 at 06:42:04AM +0200, Kaspar Brand wrote: > On 15.04.2015 18:36, Stefan Sperling wrote: > > However, the actual issue here is that mod_ssl is squatting the SSL_ > > namespace. > > Historically this may have made sense (it seems mod_ssl and OpenSSL have > > shared history/authors). Bill Rowe suggested to try moving mod_ssl's > > functions into the ap_ namespace to avoid such clashes in the future. > > Agreed that mod_ssl should avoid stepping into the SSL_* yard. As > pointed out by Jeff, ap_* is fairly foreign in the mod_ssl case, though, > and my preference is for s/SSL_/ssl_/ for functions and > s/SSL_/MODSSL_/ for constants (in the latter case, there's actually > quite some more stuff lurking - SSL_OPT_*, SSL_PROTOCOL_* etc.). It would be safer to go with a "modssl_" prefix for functions too, I've sometimes tried to use that for new things though probably not consistently. OpenSSL's libssl.so does export symbols using the "ssl_" prefix, though they are probably all internal things which shouldn't be global. Regards, Joe
Re: namespacing in mod_ssl
On Sat, Apr 18, 2015 at 9:18 AM, Stefan Sperling wrote: > So to take a first step forward, here's a diff that puts ssl_util_ssl.h > macros into the MODSSL_ namespace. +1
Re: namespacing in mod_ssl
On Wed, Apr 15, 2015 at 06:36:13PM +0200, Stefan Sperling wrote:
> However, the actual issue here is that mod_ssl is squatting the SSL_
> namespace.
> Historically this may have made sense (it seems mod_ssl and OpenSSL have
> shared history/authors). Bill Rowe suggested to try moving mod_ssl's
> functions into the ap_ namespace to avoid such clashes in the future.
Given the feedback so far, it seems we all generally agree that
the current namespacing is a problem that needs to be addressed.
I like Jeff's suggestion to split this task up into smaller changes
by looking at each symbol on a case-by-case basis.
And the alternative naming schemes suggested make sense to me.
So to take a first step forward, here's a diff that puts ssl_util_ssl.h
macros into the MODSSL_ namespace.
Index: modules/ssl/ssl_engine_init.c
===
--- modules/ssl/ssl_engine_init.c (revision 1674422)
+++ modules/ssl/ssl_engine_init.c (working copy)
@@ -148,12 +148,12 @@ apr_status_t ssl_init_Module(apr_pool_t *p, apr_po
apr_status_t rv;
apr_array_header_t *pphrases;
-if (SSLeay() < SSL_LIBRARY_VERSION) {
+if (SSLeay() < MODSSL_LIBRARY_VERSION) {
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, base_server, APLOGNO(01882)
"Init: this version of mod_ssl was compiled against "
"a newer library (%s, version currently loaded is %s)"
" - may result in undefined or erroneous behavior",
- SSL_LIBRARY_TEXT, SSLeay_version(SSLEAY_VERSION));
+ MODSSL_LIBRARY_TEXT, SSLeay_version(SSLEAY_VERSION));
}
/* We initialize mc->pid per-process in the child init,
@@ -242,7 +242,7 @@ apr_status_t ssl_init_Module(apr_pool_t *p, apr_po
#endif
ap_log_error(APLOG_MARK, APLOG_INFO, 0, s, APLOGNO(01883)
- "Init: Initialized %s library", SSL_LIBRARY_NAME);
+ "Init: Initialized %s library", MODSSL_LIBRARY_NAME);
/*
* Seed the Pseudo Random Number Generator (PRNG)
Index: modules/ssl/ssl_engine_io.c
===
--- modules/ssl/ssl_engine_io.c (revision 1674422)
+++ modules/ssl/ssl_engine_io.c (working copy)
@@ -2186,7 +2186,7 @@ long ssl_io_data_cb(BIO *bio, int cmd,
}
ap_log_cserror(APLOG_MARK, APLOG_TRACE4, 0, c, s,
"%s: %s %ld/%d bytes %s BIO#%pp [mem: %pp] %s",
-SSL_LIBRARY_NAME,
+MODSSL_LIBRARY_NAME,
(cmd == (BIO_CB_WRITE|BIO_CB_RETURN) ? "write" : "read"),
rc, argi, (cmd == (BIO_CB_WRITE|BIO_CB_RETURN) ? "to" :
"from"),
bio, argp, dump);
@@ -2196,7 +2196,7 @@ long ssl_io_data_cb(BIO *bio, int cmd,
else {
ap_log_cserror(APLOG_MARK, APLOG_TRACE4, 0, c, s,
"%s: I/O error, %d bytes expected to %s on BIO#%pp [mem:
%pp]",
-SSL_LIBRARY_NAME, argi,
+MODSSL_LIBRARY_NAME, argi,
(cmd == (BIO_CB_WRITE|BIO_CB_RETURN) ? "write" : "read"),
bio, argp);
}
Index: modules/ssl/ssl_engine_kernel.c
===
--- modules/ssl/ssl_engine_kernel.c (revision 1674422)
+++ modules/ssl/ssl_engine_kernel.c (working copy)
@@ -1654,7 +1654,7 @@ static void ssl_session_log(server_rec *s,
const char *result,
long timeout)
{
-char buf[SSL_SESSION_ID_STRING_LEN];
+char buf[MODSSL_SESSION_ID_STRING_LEN];
char timeout_str[56] = {'\0'};
if (!APLOGdebug(s)) {
@@ -1811,32 +1811,32 @@ static void log_tracing_state(const SSL *ssl, conn
*/
if (where & SSL_CB_HANDSHAKE_START) {
ap_log_cerror(APLOG_MARK, APLOG_TRACE3, 0, c,
- "%s: Handshake: start", SSL_LIBRARY_NAME);
+ "%s: Handshake: start", MODSSL_LIBRARY_NAME);
}
else if (where & SSL_CB_HANDSHAKE_DONE) {
ap_log_cerror(APLOG_MARK, APLOG_TRACE3, 0, c,
- "%s: Handshake: done", SSL_LIBRARY_NAME);
+ "%s: Handshake: done", MODSSL_LIBRARY_NAME);
}
else if (where & SSL_CB_LOOP) {
ap_log_cerror(APLOG_MARK, APLOG_TRACE3, 0, c,
"%s: Loop: %s",
- SSL_LIBRARY_NAME, SSL_state_string_long(ssl));
+ MODSSL_LIBRARY_NAME, SSL_state_string_long(ssl));
}
else if (where & SSL_CB_READ) {
ap_log_cerror(APLOG_MARK, APLOG_TRACE3, 0, c,
"%s: Read: %s",
- SSL_LIBRARY_NAME, SSL_state_string_long(ssl));
+ MODSSL_LIBRARY_NAME, SSL_state_string_long(ssl));
}
else if (where & SSL_CB_WRITE) {
ap_log_cerror(APLOG_MARK, APLOG_TRACE3, 0, c,
Re: namespacing in mod_ssl
On Wed, Apr 15, 2015 at 11:42 PM, Kaspar Brand wrote: > On 15.04.2015 18:36, Stefan Sperling wrote: > > However, the actual issue here is that mod_ssl is squatting the SSL_ > namespace. > > Historically this may have made sense (it seems mod_ssl and OpenSSL have > > shared history/authors). Bill Rowe suggested to try moving mod_ssl's > > functions into the ap_ namespace to avoid such clashes in the future. > > Agreed that mod_ssl should avoid stepping into the SSL_* yard. As > pointed out by Jeff, ap_* is fairly foreign in the mod_ssl case, though, > and my preference is for s/SSL_/ssl_/ for functions and > s/SSL_/MODSSL_/ for constants (in the latter case, there's actually > quite some more stuff lurking - SSL_OPT_*, SSL_PROTOCOL_* etc.). > +1
Re: namespacing in mod_ssl
On 15.04.2015 18:36, Stefan Sperling wrote: > However, the actual issue here is that mod_ssl is squatting the SSL_ > namespace. > Historically this may have made sense (it seems mod_ssl and OpenSSL have > shared history/authors). Bill Rowe suggested to try moving mod_ssl's > functions into the ap_ namespace to avoid such clashes in the future. Agreed that mod_ssl should avoid stepping into the SSL_* yard. As pointed out by Jeff, ap_* is fairly foreign in the mod_ssl case, though, and my preference is for s/SSL_/ssl_/ for functions and s/SSL_/MODSSL_/ for constants (in the latter case, there's actually quite some more stuff lurking - SSL_OPT_*, SSL_PROTOCOL_* etc.). > I'm not sure how README.dsov.ps should be regenerated. > It contains a refence to SSL_get_app_data2(). > For now I've only updated the .dsov.fig file. With fig2dev probably. Though in this simple case, a direct edit of README.dsov.ps seems sufficient. Kaspar
Re: namespacing in mod_ssl
On 04/15/2015 02:54 PM, Jeff Trawick wrote:
On 04/15/2015 11:36 AM, Stefan Sperling wrote:
A few months ago, OpenBSD's LibreSSL added a new function
called SSL_CTX_use_certificate_chain().
This unexpectedly broke the build of Apache's mod_ssl which defines
a function of the same name. In OpenBSD this was worked around by
patching mod_ssl, renaming the clashing function.
Since then LibreSSL has renamed to SSL_CTX_use_certificate_chain_mem().
This resolved the immediate problem and mod_ssl patches could be
dropped.
However, the actual issue here is that mod_ssl is squatting the SSL_
namespace.
Historically this may have made sense (it seems mod_ssl and OpenSSL have
shared history/authors). Bill Rowe suggested to try moving mod_ssl's
functions into the ap_ namespace to avoid such clashes in the future.
IMO it would be appropriate to instead go one by one and make sure
we're using an appropriate name to begin with for these functions that
are squatting the SSL namespace, instead of making these
often-bewildering names ugly and (still) bewildering.
AP_SSL_LIBRARY_NAME is very appropriate, but ap_SSL_set_app_data2 is
the wrong fix.
As far as the ap_prefix advice received: I don't see any ap_-prefixed
mod_ssl external symbols.
mod_ssl uses ssl_ prefixes heavily (and foo_ prefix for mod_foo in
general is common). For functions and types (i.e., stuff generally
expressed in lower case), a simple "ssl_" prefix instead of "ap_SSL_"
prefix should work and not look so different than existing mod_ssl code.
Perhaps some of the active mod_ssl devs/maintainers will speak up ;)
I have verified that no undefined references or undeclared symbols
are reported by gcc during the build with this diff.
I have tested startup of a httpd with mod_ssl loaded.
Additional testing is appreciated.
I'm not sure how README.dsov.ps should be regenerated.
It contains a refence to SSL_get_app_data2().
For now I've only updated the .dsov.fig file.
Index: modules/ssl/README.dsov.fig
===
--- modules/ssl/README.dsov.fig(revision 1673798)
+++ modules/ssl/README.dsov.fig(working copy)
@@ -339,7 +339,7 @@
4 0 0 200 0 20 8 0. 4 90 465 11745 4770 ->method\001
4 0 0 200 0 20 8 0. 4 120 1665 9945 6480
X509_STORE_CTX_get_app_data()\001
4 0 0 200 0 20 8 0. 4 120 1215 10980 6705
SSL_CTX_get_cert_store()\001
-4 0 0 200 0 20 8 0. 4 120 1020 8280 5130 SSL_get_app_data2()\001
+4 0 0 200 0 20 8 0. 4 120 1020 8280 5130 ap_SSL_get_app_data2()\001
4 0 0 100 0 18 20 0. 4 270 1290 10710 7605 OpenSSL\001
4 0 0 100 0 18 12 0. 4 180 720 10710 7785 [Crypto]\001
4 0 0 100 0 18 20 0. 4 270 1290 10935 3645 OpenSSL\001
Index: modules/ssl/mod_ssl.c
===
--- modules/ssl/mod_ssl.c(revision 1673798)
+++ modules/ssl/mod_ssl.c(working copy)
@@ -570,7 +570,7 @@
}
SSL_set_app_data(ssl, c);
-SSL_set_app_data2(ssl, NULL); /* will be request_rec */
+ap_SSL_set_app_data2(ssl, NULL); /* will be request_rec */
sslconn->ssl = ssl;
Index: modules/ssl/ssl_engine_init.c
===
--- modules/ssl/ssl_engine_init.c(revision 1673798)
+++ modules/ssl/ssl_engine_init.c(working copy)
@@ -148,12 +148,12 @@
apr_status_t rv;
apr_array_header_t *pphrases;
-if (SSLeay() < SSL_LIBRARY_VERSION) {
+if (SSLeay() < AP_SSL_LIBRARY_VERSION) {
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, base_server,
APLOGNO(01882)
"Init: this version of mod_ssl was compiled
against "
"a newer library (%s, version currently loaded
is %s)"
" - may result in undefined or erroneous
behavior",
- SSL_LIBRARY_TEXT, SSLeay_version(SSLEAY_VERSION));
+ AP_SSL_LIBRARY_TEXT,
SSLeay_version(SSLEAY_VERSION));
}
/* We initialize mc->pid per-process in the child init,
@@ -242,7 +242,7 @@
#endif
ap_log_error(APLOG_MARK, APLOG_INFO, 0, s, APLOGNO(01883)
- "Init: Initialized %s library", SSL_LIBRARY_NAME);
+ "Init: Initialized %s library", AP_SSL_LIBRARY_NAME);
/*
* Seed the Pseudo Random Number Generator (PRNG)
@@ -348,7 +348,7 @@
*/
ssl_add_version_components(p, base_server);
-SSL_init_app_data2_idx(); /* for SSL_get_app_data2() at
request time */
+ap_SSL_init_app_data2_idx(); /* for ap_SSL_get_app_data2() at
request time */
init_dh_params();
@@ -871,9 +871,9 @@
}
}
-n = SSL_CTX_use_certificate_chain(mctx->ssl_ctx,
- (char *)chain,
- skip_first, NULL);
+n = ap_SSL_CTX_use_certificate_chain(mctx->ssl_ctx,
+ (char *)chain,
+
Re: namespacing in mod_ssl
On Apr 15, 2015, at 3:54 PM, Jeff Trawick wrote: > > IMO it would be appropriate to instead go one by one and make sure we're > using an appropriate name to begin with for these functions that are > squatting the SSL namespace, instead of making these often-bewildering names > ugly and (still) bewildering. +1 Best, Victor -- Victor J. Orlikowski <> victor.j.orlikow...@alumni.duke.edu
Re: namespacing in mod_ssl
On 04/15/2015 11:36 AM, Stefan Sperling wrote:
A few months ago, OpenBSD's LibreSSL added a new function
called SSL_CTX_use_certificate_chain().
This unexpectedly broke the build of Apache's mod_ssl which defines
a function of the same name. In OpenBSD this was worked around by
patching mod_ssl, renaming the clashing function.
Since then LibreSSL has renamed to SSL_CTX_use_certificate_chain_mem().
This resolved the immediate problem and mod_ssl patches could be dropped.
However, the actual issue here is that mod_ssl is squatting the SSL_ namespace.
Historically this may have made sense (it seems mod_ssl and OpenSSL have
shared history/authors). Bill Rowe suggested to try moving mod_ssl's
functions into the ap_ namespace to avoid such clashes in the future.
IMO it would be appropriate to instead go one by one and make sure we're
using an appropriate name to begin with for these functions that are
squatting the SSL namespace, instead of making these often-bewildering
names ugly and (still) bewildering.
AP_SSL_LIBRARY_NAME is very appropriate, but ap_SSL_set_app_data2 is the
wrong fix.
I have verified that no undefined references or undeclared symbols
are reported by gcc during the build with this diff.
I have tested startup of a httpd with mod_ssl loaded.
Additional testing is appreciated.
I'm not sure how README.dsov.ps should be regenerated.
It contains a refence to SSL_get_app_data2().
For now I've only updated the .dsov.fig file.
Index: modules/ssl/README.dsov.fig
===
--- modules/ssl/README.dsov.fig (revision 1673798)
+++ modules/ssl/README.dsov.fig (working copy)
@@ -339,7 +339,7 @@
4 0 0 200 0 20 8 0. 4 90 465 11745 4770 ->method\001
4 0 0 200 0 20 8 0. 4 120 1665 9945 6480 X509_STORE_CTX_get_app_data()\001
4 0 0 200 0 20 8 0. 4 120 1215 10980 6705 SSL_CTX_get_cert_store()\001
-4 0 0 200 0 20 8 0. 4 120 1020 8280 5130 SSL_get_app_data2()\001
+4 0 0 200 0 20 8 0. 4 120 1020 8280 5130 ap_SSL_get_app_data2()\001
4 0 0 100 0 18 20 0. 4 270 1290 10710 7605 OpenSSL\001
4 0 0 100 0 18 12 0. 4 180 720 10710 7785 [Crypto]\001
4 0 0 100 0 18 20 0. 4 270 1290 10935 3645 OpenSSL\001
Index: modules/ssl/mod_ssl.c
===
--- modules/ssl/mod_ssl.c (revision 1673798)
+++ modules/ssl/mod_ssl.c (working copy)
@@ -570,7 +570,7 @@
}
SSL_set_app_data(ssl, c);
-SSL_set_app_data2(ssl, NULL); /* will be request_rec */
+ap_SSL_set_app_data2(ssl, NULL); /* will be request_rec */
sslconn->ssl = ssl;
Index: modules/ssl/ssl_engine_init.c
===
--- modules/ssl/ssl_engine_init.c (revision 1673798)
+++ modules/ssl/ssl_engine_init.c (working copy)
@@ -148,12 +148,12 @@
apr_status_t rv;
apr_array_header_t *pphrases;
-if (SSLeay() < SSL_LIBRARY_VERSION) {
+if (SSLeay() < AP_SSL_LIBRARY_VERSION) {
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, base_server, APLOGNO(01882)
"Init: this version of mod_ssl was compiled against "
"a newer library (%s, version currently loaded is %s)"
" - may result in undefined or erroneous behavior",
- SSL_LIBRARY_TEXT, SSLeay_version(SSLEAY_VERSION));
+ AP_SSL_LIBRARY_TEXT, SSLeay_version(SSLEAY_VERSION));
}
/* We initialize mc->pid per-process in the child init,
@@ -242,7 +242,7 @@
#endif
ap_log_error(APLOG_MARK, APLOG_INFO, 0, s, APLOGNO(01883)
- "Init: Initialized %s library", SSL_LIBRARY_NAME);
+ "Init: Initialized %s library", AP_SSL_LIBRARY_NAME);
/*
* Seed the Pseudo Random Number Generator (PRNG)
@@ -348,7 +348,7 @@
*/
ssl_add_version_components(p, base_server);
-SSL_init_app_data2_idx(); /* for SSL_get_app_data2() at request time */
+ap_SSL_init_app_data2_idx(); /* for ap_SSL_get_app_data2() at request time
*/
init_dh_params();
@@ -871,9 +871,9 @@
}
}
-n = SSL_CTX_use_certificate_chain(mctx->ssl_ctx,
- (char *)chain,
- skip_first, NULL);
+n = ap_SSL_CTX_use_certificate_chain(mctx->ssl_ctx,
+ (char *)chain,
+ skip_first, NULL);
if (n < 0) {
ap_log_error(APLOG_MARK, APLOG_EMERG, 0, s, APLOGNO(01903)
"Failed to configure CA certificate chain!");
@@ -946,7 +946,7 @@
* Some information about the certificate(s)
*/
-if (SSL_X509_getBC(cert, &is_ca, &pathlen)) {
+if (ap_SSL_X509_getBC(cert, &is_ca, &pathlen)) {
if (is_ca) {
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s, APLOGNO(01906)
namespacing in mod_ssl
A few months ago, OpenBSD's LibreSSL added a new function
called SSL_CTX_use_certificate_chain().
This unexpectedly broke the build of Apache's mod_ssl which defines
a function of the same name. In OpenBSD this was worked around by
patching mod_ssl, renaming the clashing function.
Since then LibreSSL has renamed to SSL_CTX_use_certificate_chain_mem().
This resolved the immediate problem and mod_ssl patches could be dropped.
However, the actual issue here is that mod_ssl is squatting the SSL_ namespace.
Historically this may have made sense (it seems mod_ssl and OpenSSL have
shared history/authors). Bill Rowe suggested to try moving mod_ssl's
functions into the ap_ namespace to avoid such clashes in the future.
I have verified that no undefined references or undeclared symbols
are reported by gcc during the build with this diff.
I have tested startup of a httpd with mod_ssl loaded.
Additional testing is appreciated.
I'm not sure how README.dsov.ps should be regenerated.
It contains a refence to SSL_get_app_data2().
For now I've only updated the .dsov.fig file.
Index: modules/ssl/README.dsov.fig
===
--- modules/ssl/README.dsov.fig (revision 1673798)
+++ modules/ssl/README.dsov.fig (working copy)
@@ -339,7 +339,7 @@
4 0 0 200 0 20 8 0. 4 90 465 11745 4770 ->method\001
4 0 0 200 0 20 8 0. 4 120 1665 9945 6480 X509_STORE_CTX_get_app_data()\001
4 0 0 200 0 20 8 0. 4 120 1215 10980 6705 SSL_CTX_get_cert_store()\001
-4 0 0 200 0 20 8 0. 4 120 1020 8280 5130 SSL_get_app_data2()\001
+4 0 0 200 0 20 8 0. 4 120 1020 8280 5130 ap_SSL_get_app_data2()\001
4 0 0 100 0 18 20 0. 4 270 1290 10710 7605 OpenSSL\001
4 0 0 100 0 18 12 0. 4 180 720 10710 7785 [Crypto]\001
4 0 0 100 0 18 20 0. 4 270 1290 10935 3645 OpenSSL\001
Index: modules/ssl/mod_ssl.c
===
--- modules/ssl/mod_ssl.c (revision 1673798)
+++ modules/ssl/mod_ssl.c (working copy)
@@ -570,7 +570,7 @@
}
SSL_set_app_data(ssl, c);
-SSL_set_app_data2(ssl, NULL); /* will be request_rec */
+ap_SSL_set_app_data2(ssl, NULL); /* will be request_rec */
sslconn->ssl = ssl;
Index: modules/ssl/ssl_engine_init.c
===
--- modules/ssl/ssl_engine_init.c (revision 1673798)
+++ modules/ssl/ssl_engine_init.c (working copy)
@@ -148,12 +148,12 @@
apr_status_t rv;
apr_array_header_t *pphrases;
-if (SSLeay() < SSL_LIBRARY_VERSION) {
+if (SSLeay() < AP_SSL_LIBRARY_VERSION) {
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, base_server, APLOGNO(01882)
"Init: this version of mod_ssl was compiled against "
"a newer library (%s, version currently loaded is %s)"
" - may result in undefined or erroneous behavior",
- SSL_LIBRARY_TEXT, SSLeay_version(SSLEAY_VERSION));
+ AP_SSL_LIBRARY_TEXT, SSLeay_version(SSLEAY_VERSION));
}
/* We initialize mc->pid per-process in the child init,
@@ -242,7 +242,7 @@
#endif
ap_log_error(APLOG_MARK, APLOG_INFO, 0, s, APLOGNO(01883)
- "Init: Initialized %s library", SSL_LIBRARY_NAME);
+ "Init: Initialized %s library", AP_SSL_LIBRARY_NAME);
/*
* Seed the Pseudo Random Number Generator (PRNG)
@@ -348,7 +348,7 @@
*/
ssl_add_version_components(p, base_server);
-SSL_init_app_data2_idx(); /* for SSL_get_app_data2() at request time */
+ap_SSL_init_app_data2_idx(); /* for ap_SSL_get_app_data2() at request time
*/
init_dh_params();
@@ -871,9 +871,9 @@
}
}
-n = SSL_CTX_use_certificate_chain(mctx->ssl_ctx,
- (char *)chain,
- skip_first, NULL);
+n = ap_SSL_CTX_use_certificate_chain(mctx->ssl_ctx,
+ (char *)chain,
+ skip_first, NULL);
if (n < 0) {
ap_log_error(APLOG_MARK, APLOG_EMERG, 0, s, APLOGNO(01903)
"Failed to configure CA certificate chain!");
@@ -946,7 +946,7 @@
* Some information about the certificate(s)
*/
-if (SSL_X509_getBC(cert, &is_ca, &pathlen)) {
+if (ap_SSL_X509_getBC(cert, &is_ca, &pathlen)) {
if (is_ca) {
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s, APLOGNO(01906)
"%s server certificate is a CA certificate "
@@ -961,8 +961,8 @@
}
}
-if (SSL_X509_match_name(ptemp, cert, (const char *)s->server_hostname,
-TRUE, s) == FALSE) {
+if (ap_SSL_X509_match_name(ptemp, cert, (const char *)s->server_hostname,
+ TRUE, s) == FALSE) {
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s, APLOGNO(01909)
