Why doesn't the server accept an SSL certificate?

Question

Apache HTTP Server

After configuring mod_ssl on the server (apache 2.2), a self-signed localhost.crt certificate and a localhost.key key
were created. The openssl.cnf config is as follows

Look

# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#

# This definition stops the following lines choking if HOME isn't
# defined.
HOME			= .
RANDFILE		= $ENV::HOME/.rnd

# Extra OBJECT IDENTIFIER info:
#oid_file		= $ENV::HOME/.oid
oid_section		= new_oids

# To use this configuration file with the "-extfile" option of the
# "openssl x509" utility, name here the section containing the
# X.509v3 extensions to use:
# extensions		= 
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)

[ new_oids ]

# We can add new OIDs in here for use by 'ca', 'req' and 'ts'.
# Add a simple OID like this:
# testoid1=1.2.3.4
# Or use config file substitution like this:
# testoid2=${testoid1}.5.6

# Policies used by the TSA examples.
tsa_policy1 = 1.2.3.4.1
tsa_policy2 = 1.2.3.4.5.6
tsa_policy3 = 1.2.3.4.5.7

####################################################################
[ ca ]
default_ca	= CA_default		# The default ca section

####################################################################
[ CA_default ]

dir		= /etc/pki/CA		# Where everything is kept
certs		= $dir/certs		# Where the issued certs are kept
crl_dir		= $dir/crl		# Where the issued crl are kept
database	= $dir/index.txt	# database index file.
#unique_subject	= no			# Set to 'no' to allow creation of
          # several ctificates with same subject.
new_certs_dir	= $dir/newcerts		# default place for new certs.

certificate	= /etc/pki/tls/certs/localhost.crt 	# The CA certificate
serial		= $dir/serial 		# The current serial number
crlnumber	= $dir/crlnumber	# the current crl number
          # must be commented out to leave a V1 CRL
crl		= $dir/crl.pem 		# The current CRL
private_key	= /etc/pki/tls/private/localhost.key# The private key
RANDFILE	= $dir/private/.rand	# private random number file

x509_extensions	= usr_cert		# The extentions to add to the cert

# Comment out the following two lines for the "traditional"
# (and highly broken) format.
name_opt 	= ca_default		# Subject Name options
cert_opt 	= ca_default		# Certificate field options

# концовку подрезал, если необходимо могу дополнить.

When entering commands, I am in the /CA/ directory (and, by the way, does it matter where it is?)
Request for a client certificate

# openssl req -new -newkey rsa:1024 -nodes -keyout client01.key \
        -subj /C=RU/ST=Msk/L=Msk/O=Inc/OU=Web/CN=usr/[email protected] \
        -out client01.csr

I sign the request

# openssl ca -config ../tls/openssl.cnf -in client01.csr -out client01.crt -batch

I complete this whole thing

# openssl pkcs12 -export -in client01.crt -inkey client01.key \
        -certfile localhost.crt -out client01.p12 -passout pass:q1w2e3

There are no errors when creating certificates.
But when I go to https://test.ru/ it asks me to choose a certificate, I choose my own, but the server does not accept authorization

google chrome

Этот сервер требует сертификат для аутентификации и не принял сертификат, отправленный браузером. Срок действия вашего сертификата, возможно, истек, или сервер не доверяет издателю. Можно повторить попытку, используя другой сертификат (при его наличии), или получить допустимый сертификат.
Код ошибки: ERR_BAD_SSL_CLIENT_AUTH_CERT

What could be the problem?
I haven’t worked with certificates before, maybe there are some standard pitfalls, in the configuration settings or in something else?

Answer 1

It would be necessary to look at the virtual host (or root site) config, as well as those places where you screwed the ssl authorization.

Answer 2

Usually, some of the servers don't accept self-signed certificates because they won't be trusted by servers. It would be highly recommended that go through third party certificate authority such as Symatecn, GeoTrust, Thawte and RapidSSL.