Я запускаю сервер openssl на своем устройстве CentOS. Я использую сертификат с истекшим сроком действия и ожидаю увидеть сообщение «Ошибка центра сертификации» в /var/log/messages, но мой системный журнал не записывает сообщения аутентификации. Как я могу это исправить?

Ожидаемое сообщение:

Certificate error: authority and subject key identifier mismatch

Шаги: На сервере:

openssl s_server -debug -accept 4443 -cert /tmp/expired.crt -key /tmp/expired.key -tls1 -no_dhe -WWW -cipher DES-CBC3-SHA 1>/tmp/server-normal-tls1-DES-CBC3-SHA-STDOUT 2>/tmp/server-normal-tls1-DES-CBC3-SHA-STDERR &

На клиенте: openssl s_client -connect 5.0.0.1:4443 -tls1 -CAfile /tmp/all.pem -cipher DES-CBC3-SHA 1>/tmp/client-normal-tls1-DES-CBC3-SHA-STDOUT 2>/tmp/client-normal-tls1-DES-CBC3-SHA-STDERR; echo

Наблюдал /var/log/messages на сервере:

[root@<hostname> ~]# cat /var/log/messages

<6>1 2020-07-01T00:04:46.230901+05:30 <hostname> kernel  - - e1000: eth0 NIC Link is Up 1000 
Mbps Full Duplex, Flow Control: None
<6>1 2020-07-01T00:04:46.238043+05:30 <hostname> kernel  - - ADDRCONF(NETDEV_UP): eth0: link is not ready
<6>1 2020-07-01T00:04:46.238084+05:30 <hostname> kernel  - - 8021q: adding VLAN 0 to HW     filter on device eth0
<6>1 2020-07-01T00:04:46.263186+05:30 <hostname> kernel  - - ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
<189>1 2020-07-01T00:04:46.354565+05:30 <hostname> NET 3206 - -  /etc/sysconfig/network-scripts/ifup-post : updated /etc/resolv.conf
<6>1 2020-07-01T00:04:46.421362+05:30 <hostname> kernel  - - e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
<6>1 2020-07-01T00:04:46.428795+05:30 <hostname> kernel  - - ADDRCONF(NETDEV_UP): eth1: link is not ready
<6>1 2020-07-01T00:04:46.428838+05:30 <hostname> kernel  - - 8021q: adding VLAN 0 to HW filter on device eth1
<6>1 2020-07-01T00:04:46.444970+05:30 <hostname> kernel  - - ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
<6>1 2020-07-01T00:04:46.581818+05:30 <hostname> kernel  - - e1000: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
<6>1 2020-07-01T00:04:46.589378+05:30 <hostname> kernel  - - ADDRCONF(NETDEV_UP): eth2: link is not ready
<6>1 2020-07-01T00:04:46.589391+05:30 <hostname> kernel  - - 8021q: adding VLAN 0 to HW filter on device eth2
<6>1 2020-07-01T00:04:46.605267+05:30 <hostname> kernel  - - ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
<189>1 2020-07-01T00:04:47.419669+05:30 <hostname> NET 3368 - -  /etc/sysconfig/network-scripts/ifdown-post : updated /etc/resolv.conf
<6>1 2020-07-01T00:04:47.829926+05:30 <hostname> kernel  - - e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
<6>1 2020-07-01T00:04:47.842681+05:30 <hostname> kernel  - - ADDRCONF(NETDEV_UP): eth1: link is not ready
<6>1 2020-07-01T00:04:47.842802+05:30 <hostname> kernel  - - 8021q: adding VLAN 0 to HW filter on device eth1
<6>1 2020-07-01T00:04:47.871609+05:30 <hostname> kernel  - - ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
<30>1 2020-07-01T00:04:48.209339+05:30 <hostname> dnsmasq 1911 - -  reading /etc/resolv.conf
<30>1 2020-07-01T00:04:48.209377+05:30 <hostname> dnsmasq 1911 - -  using nameserver 10.204.208.221#53
<30>1 2020-07-01T00:04:48.209389+05:30 <hostname> dnsmasq 1911 - -  using nameserver 10.204.208.219#53
<30>1 2020-07-01T00:04:48.209398+05:30 <hostname> dnsmasq 1911 - -  using nameserver 10.216.116.220#53
<30>1 2020-07-01T00:04:48.209416+05:30 <hostname> dnsmasq 1911 - -  using local addresses only for unqualified names
<6>1 2020-07-01T00:04:48.821696+05:30 <hostname> kernel  - - e1000: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
<6>1 2020-07-01T00:04:48.829409+05:30 <hostname> kernel  - - ADDRCONF(NETDEV_UP): eth2: link is not ready
<6>1 2020-07-01T00:04:48.829418+05:30 <hostname> kernel  - - 8021q: adding VLAN 0 to HW filter on device eth2
<6>1 2020-07-01T00:04:48.845368+05:30 <hostname> kernel  - - ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
<13>1 2020-07-01T00:12:41.993789+05:30 <hostname> root 3800 - -  hello
<6>1 2020-07-01T00:28:41.528583+05:30 <hostname> kernel  - - Kernel logging (proc) stopped.
<46>1 2020-07-01T00:28:41.539523+05:30 <hostname> rsyslogd  - -  [origin software="rsyslogd" swVersion="5.8.10" x-pid="1229" x-info="http://www.rsyslog.com"] exiting on signal 15.

Конфигурация /etc/rsyslog.conf:

#### RULES ####

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                                 /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;user;auth;authpriv;cron.none;syslog;daemon                /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog


# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 *

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log
1
N.C. 2 Июл 2020 в 11:20
Даже если openssl s_server записывает в системный журнал, почему вы ожидаете, что это сообщение появится в журнале сервера. Сертификат сервера проверяется клиентом, а не сервером. В частности, сертификат с истекшим сроком действия терпит неудачу, потому что системные часы клиента говорят, что время/дата находятся в будущем от даты окончания сертификата. Насколько я знаю, сервер не знает, почему клиент отказывается принять сертификат.
 – 
Philip Couling
2 Июл 2020 в 12:00

2 ответа

Просто потому, что какое бы программное обеспечение вы ни использовали, оно не отправляет сообщения в системный регистратор. OpenSSL сам по себе не предназначен для запуска в качестве демона и не настроен по умолчанию (или вообще) для входа в системный журнал.

Процессы должны намеренно отправлять сообщения системному регистратору, чтобы rsyslog (или другой системный регистратор) забрал их и в конечном итоге записал в файл журнала или куда-либо еще.

1
Pedro 2 Июл 2020 в 11:24

Вы спрашиваете, почему сервер SSL (openssl s_server) не записывает причину, по которой его собственный сертификат сервера SSL не прошел проверку.

Я не верю, что это возможно. Сертификат сервера (обычно) не проверяется сервером.

Сертификат сервера проверяется клиентом. В частности, сертификат с истекшим сроком действия не работает, потому что "Дата не позже" находится в прошлом по отношению к системным часам на клиенте. Поскольку сервер не знает (он может только догадываться), какое время думает клиент, сервер никогда не узнает, будет ли сертификат принят клиентом.

Насколько я знаю, когда сертификат не проходит проверку на клиенте, клиент не информирует сервер о том, почему эта проверка не удалась. Он просто закрывает соединение, потому что вообще не доверяет серверу.


Как указывает Педро, openssl s_server не должен записывать в системный журнал. Даже если он может определить причину отключения клиента, у него нет возможности это сделать (насколько мне известно). Вам необходимо зафиксировать выходные данные и опубликовать их через клиент системного журнала, например logger. .

0
Philip Couling 2 Июл 2020 в 12:19
Спасибо за ваш ответ @PhilipCouling. Как в этом случае я смогу проверить причину сбоя аутентификации на клиенте? Там будет какое-то сообщение журнала с указанием причины сбоя аутентификации.
 – 
N.C.
2 Июл 2020 в 12:54