Verify error num 10 certificate has expired - Исправление ошибок и поиск оптимальных решений проблем

Содержание

Certificate has expired #2900
Comments
Проблемы с корневым сертификатом или что-то около того
Arch Linux
#1 2021-01-21 01:15:03
Certificate expired or common name invalid on selected websites
#2 2021-01-21 01:19:46
Re: Certificate expired or common name invalid on selected websites
#3 2021-01-21 01:23:31
Re: Certificate expired or common name invalid on selected websites
#4 2021-01-21 01:35:32
Re: Certificate expired or common name invalid on selected websites
#5 2021-01-21 01:41:09
Re: Certificate expired or common name invalid on selected websites
#6 2021-01-21 01:49:27
Re: Certificate expired or common name invalid on selected websites
#7 2021-01-21 15:31:40
Re: Certificate expired or common name invalid on selected websites
Solved DST Root CA X3 certificate has expired
gldecurtins
SirDice
gldecurtins
SirDice
gldecurtins
grahamperrin@
gldecurtins
gldecurtins
BjarneB
gldecurtins
SirDice
BjarneB
SirDice
gldecurtins

Certificate has expired #2900

Hi all!
Strange problem with ssl:

CONNECTED(00000003)
depth=0 C = —, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = share, emailAddress = root@share
verify error:num=18:self signed certificate
verify return:1
depth=0 C = —, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = share, emailAddress = root@share
verify error:num=10:certificate has expired
notAfter=Aug 14 02:50:25 2015 GMT
verify return:1
depth=0 C = —, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = share, emailAddress = root@share
notAfter=Aug 14 02:50:25 2015 GMT
verify return:1

Date is wrong. How it could be?

Server certificate
subject=/C=—/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=share/emailAddress=root@share
issuer=/C=—/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=share/emailAddress=root@share

No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits

SSL handshake has read 1334 bytes and written 373 bytes

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 0BF579F4BC254066CCCC990705BA8678F7D0097C5C5783A367ADC87BC8A07283
Session-ID-ctx:
Master-Key: E95E18A72CA7FB1D533CE83B8E7DC39D623AE151E324AF9BB51646B464843315EE86AA46026ED7DBC99C90B9AA5E6674
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 300 (seconds)

Problem with openssl or with certificates or apache missconfiguration? Any ideas?

The text was updated successfully, but these errors were encountered:

Источник

Проблемы с корневым сертификатом или что-то около того

Проблема следующего характера. Нужно было тут сынтегрироваться с этими ребятами: incust.com. Ну вроде бы ничего сложного если не одно НО.

При доступе через МТС (телефон в роли модема) браузеры и curl ругаются на ssl сертификат. Openssl возвращает следующее:

Если использую местного провайдера через мини микротик (MikroTik hAP Lite), то в Chrome получаю разрыв соединения, curl все так же ругается на сертификат.

Вот что пишет curl:

Что делал, переустанавливал пакет app-misc/ca-certificates. Делал update-ca-certificates. Перезагружался после этого. Результат тот же.

В чем может быть проблема? Какие еще данные нужны для отладки?

Т.е. их возможно зацепило случайно? А я блин башку сломал себе, думал у меня косяк. Вот отстой.

Но хотелось бы услышать ещё чьё нибудь мнение.

В любом случае огромное спасибо сейчас помощь.

В любом случае вот что странно. С телефона то нормально открывает.

Да, это блэклист, я этот сертификат(с такими датами начала/окончания срока действия) регулярно видел, пока не настроил обход блокировок.

Значит там трафик идет через другую систему блокировки, которая менее топорная — у больших провайдеров по определению не может быть единой системы блокировки(мы тут говорим о русских провайдерах, Китай с Золотым Щитом не в счёт :-))

Слушай, а что мне делать то теперь 🙂

Настраивать обход блокировок, очевидно же 🙂

Я попробовал через «другого провайдера». Сертификат прошел проверку.

curl —ssl https://incust.com -v
* About to connect() to incust.com port 443 (#0)
* Trying 192.99.62.181.
* Connected to incust.com (192.99.62.181) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=incust.com,O=ARoglyph Inc.,L=Alexandria,ST=Virginia,C=US
* start date: фев 03 16:57:00 2016 GMT
* expire date: фев 03 16:57:00 2019 GMT
* common name: incust.com
* issuer: CN=StartCom Class 3 OV Server CA,OU=StartCom Certification Authority,O=StartCom Ltd.,C=IL

★★★★★ ( 21.03.17 11:52:50 MSK )
Последнее исправление: imul 21.03.17 11:53:32 MSK (всего исправлений: 1)

Проблема в следующем. Не сильно настраивал тор, но всякое барахло типа pornhub’а открывать стало. Однако этот incust все так же срется. Может дело все же в моей конфигурации. На соседней виндовой машине все ок.

Вот тоже самое через тор. Я все же ссылаюсь на некую поломку в системе.

openssl s_client -showcerts -connect incust.com:443 ★★★★★ ( 21.03.17 15:14:12 MSK )

Все оказалось куда проще 🙂 Старкомовский у них ключик, в gentoo их удалили.

Источник

Arch Linux

You are not logged in.

#1 2021-01-21 01:15:03

Certificate expired or common name invalid on selected websites

The error seems to be there most notably on i.redd.it and any stackexchange (including stackoverflow etc.) website.

On i.reddit.com, it says the certificate is invalid and valid only for reddit.com, *.reddit.com:
SSL_ERROR_BAD_CERT_DOMAIN (in Firefox)
NET::ERR_CERT_COMMON_NAME_INVALID (in Brave)

and on stackoverflow.com, it says the certificate expired.
SEC_ERROR_EXPIRED_CERTIFICATE (in Firefox)
NET::ERR_CERT_DATE_INVALID (in Brave)
Looking at the certificate in this case, it says that the certificate expired on 1/3/2021

This is not a problem with my router/ISP because the websites do work on my other devices.
Running openssl s_client -connect stackoverflow.com:443 -showcerts also says that the certificate has expired.
Though running the same thing with i.redd.it doesn’t tell me any such thing.

It is not a problem with the websites or the browser itself either.

It is «probably» not a problem with https://archlinux.org/news/nss3511-1-an … ervention/
either, because if it were it would say that the certificate authority is invalid rather than giving such specific errors on a few specific websites.

I am guessing it is a problem with my internet configuration.
Thanks for reading through this.

Last edited by nzec (2021-01-21 01:17:23)

#2 2021-01-21 01:19:46

Re: Certificate expired or common name invalid on selected websites

Is the system clock set incorrectly?

#3 2021-01-21 01:23:31

Re: Certificate expired or common name invalid on selected websites

Is the system clock set incorrectly?

It is not, the time is correct to the very seconds and is the correct timezone as well.

I had followed the instructions here: https://wiki.archlinux.org/index.php/Systemd-timesyncd
to synchronize my clock to the ntp pool servers about a year ago.

#4 2021-01-21 01:35:32

Re: Certificate expired or common name invalid on selected websites

What is the full output of openssl s_client -connect stackoverflow.com:443 -showcerts showing the certificate has expired?

#5 2021-01-21 01:41:09

Re: Certificate expired or common name invalid on selected websites

Also, I am setting the DNS servers to 1.1.1.1 and 1.0.0.1 using the steps given here: https://wiki.archlinux.org/index.php/Ne … NS_servers

Last edited by nzec (2021-01-21 01:53:29)

#6 2021-01-21 01:49:27

Re: Certificate expired or common name invalid on selected websites

Edit:
What if you try one of the IP addresses I resolved stackoverflow.com to (other address 151.101.129.69 151.101.65.69 151.101.1.69)

Last edited by loqs (2021-01-21 04:45:37)

#7 2021-01-21 15:31:40

Re: Certificate expired or common name invalid on selected websites

What if you try one of the IP addresses I resolved stackoverflow.com to (other address 151.101.129.69 151.101.65.69 151.101.1.69)

Gives the exact same thing.
The only difference being the Session Key and Session ID.
For comparison, here is the one without directly resolving it:

And here is the one after resolving it:

I did some more testing, and found that checking the same from another Arch install on a separate hard drive, works fine,

I tested the same with testssl.sh which is really nice because it gives the most amount of output. It gives the following:

running testssl -oA output stackoverflow.com , here is the output.html (expired):
https://gistcdn.rawgit.org/nzec/a7d3a09 … rflow.html
running testssl -oA output i.redd.it , here is the output.html (certificate does not match supplied URI):
https://gistcdn.rawgit.org/nzec/a7d3a09 … eddit.html

I uninstalled NetworkManager and chrooted from the separate hard drive and installed NetworkManager again, and the problem persisted.
I am guessing it is not a problem with DNS because it resolves correctly and even if I manually resolve it, the problem still persists.

The same problem exists with all the reddit cdn websites. I also found a few other websites with the same problem.
I read https://wiki.archlinux.org/index.php/Tr … r_Security and tried reinstalling ca-certificates and did update-ca-trust but that didn’t do anything.
The bizarre thing is that, the problem isn’t with the installed CA certs, the problem is that somehow, I am getting the wrong certificate from the websites themselves (which work fine on all other devices).

This is driving me crazy. I might just do a fresh install.

Источник

Solved DST Root CA X3 certificate has expired

gldecurtins

One of Let’s Encrypts Root Certificates (DST Root CA X3) has expired, as announced a few months back.
I’m using the security/dehydrated pkg to keep my server certificates up to date — which seem to work just fine.

Now I face the issue that client software still complains about expired certificates. How would I fix this?

I wonder if there is a system wide fix for this behaviour.

SirDice

Administrator

Reactions: grahamperrin@ and gldecurtins

gldecurtins

I’m running FreeBSD:13:amd64, quarterly pkgs which uses version 3.63. Last version would be 3.69_1.
So it looks like I’ve to be patient.

SirDice

Administrator

gldecurtins

So today I was able to install the quarterly pkg upgrade. Now ca_root_nss is bumped to 3.69_1.

Nevertheless my openssl still reports an expired certificate.

grahamperrin@

gldecurtins

Yes, I think both, system and pkg are up to date.

Reactions: grahamperrin@

Reactions: ralphbsz

gldecurtins

BjarneB

You receive the full certificate chain in the response, so it should not matter which root certificates you have installed.

The wrong certificate you are seeing in the response is actually what is included in package ca_root_nss:

Maybe you have some special config somewhere that tells openssl to ignore fullchain response and look at local files instead?
I have no idea if that is even possible.

gldecurtins

Hmm yeah. I just wonder why two different systems (Ubuntu / FreeBSD) come up with two different certificate chains and finally conclusions on the validity.

Ultimately I have at least www/matomo which uses a Python script to import some apache log files which fails since weeks with the following Error:

SirDice

Administrator

Try updating your security/ca_root_nss once more, quarterly should have 3.69_1 and it works with that. Builds have been done but I’m not sure if everything has been synced to the package mirrors yet.

I haven’t updated this system yet and it just happens to have the same version as quarterly has.

BjarneB

gldecurtins
I agree it is wierd, I have freebsd and linux systems working without issues, it seems to be some speciality on your setup.
I do notice however that on all mine servers, SirDice’s output and your linux there is:

That is depth=2, but on you freebsd, depth=3

This is different:

Reactions: Jose

SirDice

Administrator

gldecurtins

I found the reason, after setting up a virtual machine with FreeBSD 13.0.
All the configuration files were the same, versions of ca_root_nss as well.

The only difference was that the folder /usr/local/share/certs contained my let’s encrypt certificates (security/dehydrated) as well.
After moving them to a different folder and executing certctl rehash it started to work as expected.

I thought it was a good idea to put them into the certs folder — looks like I’ve been proven wrong. Where do you store them?

Thanks for all your proposals and patience, appreciate!

Источник

Open

Issue created Sep 01, 2021 by Ben Prescott_@bprescott_🌂Developer

Expiry of ‘DST Root CA X3’ public TLS root — September / October 2021

Problem to solve
Troubleshooting steps
- TLS issues in CI jobs
Fix
- Client fix
- The affected server has a Let’s Encrypt certificate
- Other cases
Further details

Problem to solve

As a result of the DST Root CA X3 public root certificate expiring Sep 30 14:01:15 2021 GMT, GitLab Support and Customers may encounter TLS errors in:

Command output (such as GitLab CI logs).
The GitLab system logs.
In systems which connect into GitLab (such as Jira or Jenkins).
Load balancers and other systems acting as TLS clients.

These errors may include:

certificate verify failed

error code 10: certificate has expired, or more specifically:

depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT

verification errors for C = US, O = Let's Encrypt, CN = R3 (which should specifically be a client fix)

depth=1 C = US, O = Let's Encrypt, CN = R3
verify error:num=20:unable to get local issuer certificate

Inconsistent behavior may be observed. Some clients won’t correctly validate the root and / or intermediate validity dates, and allow the TLS handshake to proceed, others will terminate the handshake (correctly!).

For example: while some clients of GitLab such as Git, Docker (pulling containers) or a client of the package repositories may fail with errors, the same client on other servers, or some browsers, might not report any issues. Browsers cache common intermediate certificates, so may be able to construct a valid chain, and may ignore the supplied intermediate. Or, they may just fail to properly validate the dates.

If the GitLab server is acting as a client, for example: webhooks, the errors will be in the GitLab server logs.

Troubleshooting the certificate has expired error is likely to focus on the server’s certificate, which won’t have expired. None of the certificates in the chain will have expired either, the expired certificate will be in the client’s trust store.

Alternatively, if the root has been include in the chain, clients may generate more unusual errors, because there will be an expired (and self-signed) certificate present in the chain.

Be sure to thoroughly check the certificate chain if certificate has expired errors are being generated. In the example below all certificates in the chain are dated well after September 30th, but the final one was signed by the DST Root CA X3 and so the error would relate to the root, not the certificates in the chain.

notAfter=Nov 29 23:21:27 2021 GMT
    commonName                = gitlab.example.com
issuer=
    countryName               = US
    organizationName          = Let's Encrypt
    commonName                = R3

notAfter=Sep 15 16:00:00 2025 GMT
subject=
    countryName               = US
    organizationName          = Let's Encrypt
    commonName                = R3
issuer=
    countryName               = US
    organizationName          = Internet Security Research Group
    commonName                = ISRG Root X1

notAfter=Sep 30 18:14:03 2024 GMT
subject=
    countryName               = US
    organizationName          = Internet Security Research Group
    commonName                = ISRG Root X1
issuer=
    organizationName          = Digital Signature Trust Co.
    commonName                = DST Root CA X3

This is a Let’s Encrypt example, and it’d be expected that the clients would trust ISRG Root X1 and stop validating the chain.

Troubleshooting steps

Determine the affected server. For example, if GitLab runners are generating the errors, then the server is the GitLab server.
Query the server using openssl

echo | openssl s_client -servername gitlab.example.com -connect gitlab.example.com:443

Check the issuer of the last certificate. The following example shows gitlab.com’s chain (which is not affected) — the issuer is Comodo AAA Certificate Services.

Certificate chain
 0 s:CN = gitlab.example.com
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

Look at the STDERR in particular, this may indicate which certificate has is generating the error. In this example, there is no error — run on an Ubuntu server with /etc/ssl/certs/ISRG_Root_X1.pem

$ echo | openssl s_client -servername gitlab.example.com -connect gitlab.example.com:443 >/dev/null
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = gitlab.example.com
verify return:1
DONE

But on a Centos 7 server, it instead outputs:

depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
DONE

TLS issues in CI jobs

See #339842 (comment 695568359) for some guidance.

If you raise a ticket with GitLab support, please include a raw job log so we can see the context of the errors.

Fix

If you can fix the issue solely client side, then don’t make any server changes. If you’re running a Let’s Encrypt certificate, it renews regularly, and so any manual changes to the certificate chain are likely to be over-written within a couple of months.

An issue has been opened to support force_chain via gitlab.rb — please 👍 and chime in on the issue: omnibus-gitlab#6431. (More details: #339842 (comment 694649934))

Client fix

Add the ISRG Root X1 certificate to affected clients’ trust stores.

Centos/RHEL

second step distrusts the expired root read more

sudo wget --no-check-certificate  -O /etc/pki/ca-trust/source/anchors/isrgrootx1.pem 
      https://letsencrypt.org/certs/isrgrootx1.pem
grep --after-context=20 'DST Root CA X3' /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem | 
      sudo tee /etc/pki/ca-trust/source/blacklist/dst_root_ca_x3.pem
sudo update-ca-trust extract

Debian/Ubuntu
- Checks if ISRG_Root_X1.pem already exists in the trust store, and then doesn’t add it again.
- Distrust DST Root CA X3 by editing /etc/ca-certificates.conf so mozilla/DST_Root_CA_X3.crt is prefixed with !. Read more.
```
if test -e /etc/ssl/certs/ISRG_Root_X1.pem ; then
  :
else
  sudo wget --no-check-certificate  -O /usr/local/share/ca-certificates/isrgrootx1.crt 
        https://letsencrypt.org/certs/isrgrootx1.pem
fi
sudo sed -i 's~^mozilla/DST_Root_CA_X3.crt$~!mozilla/DST_Root_CA_X3.crt~g' /etc/ca-certificates.conf
   # verify change
grep DST_Root /etc/ca-certificates.conf
sudo update-ca-certificates --fresh
```
For other browsers, distributions and operating systems search ‘add root certificate to PLATFORM’ for a selection of guides.
Autoscale runner: TBC, see possible workaround in #339842 (comment 693566146)
GitLab servers: if the GitLab server is the client (for example: webhooks, repository cloning) then /opt/gitlab/embedded/ssl/certs/cacert.pem should be sufficient to trust ISRG Root X1.
- If that file does not contain a reference to this certificate authority, additional roots are added by copying them, one certificate per file, to /etc/gitlab/trusted-certs/ and running gitlab-ctl reconfigure. (more: the Omnibus documentation)
- Please comment below or raise a support ticket if you find cases where GitLab (as a client) runs into issues with DST Root CA X3 expiring.
Manually:
- Download self-signed ISRG Root X1 certificate in the required format from Let’s Encrypt
- Follow the steps for your client to import it into the trust store.
- If your client’s OS still distributes DST Root CA X3 but allows you to flag it as distrusted, do so. Read more.
- A copy of DST Root CA X3 extracted from Centos7: dst_root_ca_x3.pem

The affected server has a Let’s Encrypt certificate

For example, a GitLab server.

Client fixes, where required. If this resolves the issue, don’t make any server-side fixes.
If some clients still refuse to handshake and if the server’s chain contains the ISRG Root X1 certificate cross signed by DST Root CA X3

 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3

Back up and edit the server certificate /etc/gitlab/ssl/gitlab.example.com.crt. Remove the certificate at the bottom of the file. This is bounded by -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- — these lines should be removed as well.
Restart NGINX gitlab-ctl restart nginx
Verify the chain is correct and complete with OpenSSL, see troubleshooting steps.

This is based on testing with Centos7, more details in #339842 (comment 691520998)

Other cases

Client fixes, where required. If this resolves the issue, don’t make any server-side fixes.
Correct the certificate chain on the affected servers, so the chain directs clients to a valid root.
- The customer’s certificate authority will have documentation online about what intermediates to use. Google for the intermediate CA name which issued the customer’s server certificate.

Further details

Details of the root that is due to expire:

$  /opt/gitlab/embedded/bin/openssl x509   -noout -dates -subject -issuer -nameopt multiline 
      -ext subjectAltName  -in   DST_Root_CA_X3.pem
notBefore=Sep 30 21:12:19 2000 GMT
notAfter=Sep 30 14:01:15 2021 GMT
subject=
    organizationName          = Digital Signature Trust Co.
    commonName                = DST Root CA X3
issuer=
    organizationName          = Digital Signature Trust Co.
    commonName                = DST Root CA X3

One common Certificate Authority that cross-signs their intermediate certificates with DST Root CA X3 is Let’s Encrypt.

For example:

# /opt/gitlab/embedded/bin/openssl x509 -noout -dates -subject -issuer  -nameopt multiline 
      -ext subjectAltName  -in /etc/gitlab/ssl/gitlab.example.com.crt
notBefore=Aug 31 23:21:28 2021 GMT
notAfter=Nov 29 23:21:27 2021 GMT
subject=
    commonName                = gitlab.example.com
issuer=
    countryName               = US
    organizationName          = Let's Encrypt
    commonName                = R3
X509v3 Subject Alternative Name: 
    DNS:gitlab.example.com

A server might present with a valid certificate like this, with a validity well past the end of September. This is an example from Let’s Encrypt, but other certificate authorities will be affected.

If the chain is constructed incorrectly, intermediate(s) which direct the client to DST Root CA X3 will have been concatenated onto the server’s certificate.

For example: the second certificate could look something like this, where the issuer is DST Root CA X3. Alternatively, there may be additional certificates in the chain, and the last one will have that issuer.

# /opt/gitlab/embedded/bin/openssl x509   -noout -dates -subject -issuer  -nameopt multiline 
      -ext subjectAltName  -in ./2
notBefore=Oct  7 19:21:40 2020 GMT
notAfter=Sep 29 19:21:40 2021 GMT
subject=
    countryName               = US
    organizationName          = Let's Encrypt
    commonName                = R3
issuer=
    organizationName          = Digital Signature Trust Co.
    commonName                = DST Root CA X3

Note that in this case, the intermediate expires before the root.

An alternative chain:

# /opt/gitlab/embedded/bin/openssl x509   -noout -dates -subject -issuer  -nameopt multiline 
      -ext subjectAltName  -in ./2new
notBefore=Sep  4 00:00:00 2020 GMT
notAfter=Sep 15 16:00:00 2025 GMT
subject=
    countryName               = US
    organizationName          = Let's Encrypt
    commonName                = R3
issuer=
    countryName               = US
    organizationName          = Internet Security Research Group
    commonName                = ISRG Root X1

followed by:

# /opt/gitlab/embedded/bin/openssl x509   -noout -dates -subject -issuer  -nameopt multiline 
      -ext subjectAltName  -in ./3new
notBefore=Jan 20 19:14:03 2021 GMT
notAfter=Sep 30 18:14:03 2024 GMT
subject=
    countryName               = US
    organizationName          = Internet Security Research Group
    commonName                = ISRG Root X1
issuer=
    organizationName          = Digital Signature Trust Co.
    commonName                = DST Root CA X3

This is an example of an intermediate that exceeds the expiry of the root, and is the chain being presented by a GitLab server at the start of September 2021.

Let’s Encrypt has published two relevant blog posts:

About the DST Root CA X3
Let’s Encrypts’ new CA structure

ISRG Root X1 will be supported by some clients natively, eg: Ubuntu 18.04. From their first blog post, I think it’s expected that clients will chain back to ISRG Root X1 and only use DST Root CA X3 if they don’t trust Let’s Encrypt’s own ISRG root.

$ openssl x509   -noout -dates -subject -issuer  -nameopt multiline -ext subjectAltName  
      -in ./ISRG_Root_X1.pem
notBefore=Jun  4 11:04:38 2015 GMT
notAfter=Jun  4 11:04:38 2035 GMT
subject=
    countryName               = US
    organizationName          = Internet Security Research Group
    commonName                = ISRG Root X1
issuer=
    countryName               = US
    organizationName          = Internet Security Research Group
    commonName                = ISRG Root X1

Edited Oct 05, 2021 by Ben Prescott_

Источник

I have two Ubuntu 18.04 machines. One virtual based on bento/ubuntu-18.04 Vagrant box and one laptop.

Since yesterday when I try to clone a repository the virtual machine will show a certificate error.

vagrant@mybox:~$ git clone https://somehostedgitrepo/myrepo.git/
Cloning into 'myrepo'...
fatal: unable to access 'https://somehostedgitrepo/myrepo.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

On my laptop it still works.

When I verify

openssl s_client -connect somehostedgitrepo:443

It shows that the certificate is expired

depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify error:num=10:certificate has expired
notAfter=Jun  4 11:04:38 2035 GMT
CONNECTED(00000005)
---
Certificate chain
 0 s:CN =somehostedgitrepo
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFLjCCBBagAwIBAgISAzIS8MDFK/RLB5bSwMulrF77MA0GCSqGSIb3DQEBCwUA
...
JJzXxLHT6RkWXPDM9wyTnQl14gC6Mtp+S3IbBbGoidnnOw==
-----END CERTIFICATE-----
subject=CN = somehostedgitrepo

issuer=C = US, O = Let's Encrypt, CN = R3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4586 bytes and written 402 bytes
Verification error: certificate has expired
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
....

On my laptop I have

depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = somehostedgitrepo
verify return:1
CONNECTED(00000005)
---
Certificate chain
 0 s:CN = somehostedgitrepo
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFLjCCBBagAwIBAgISAzIS8MDFK/RLB5bSwMulrF77MA0GCSqGSIb3DQEBCwUA
...

Notice that on my VM the top of the output shows

notAfter=Jun  4 11:04:38 2035 GMT

I noticed that there is a difference in the file /etc/ca-certificates.conf

diff ca-certificates.conf /etc/ca-certificates.conf
46c46
< mozilla/DST_Root_CA_X3.crt
---
> !mozilla/DST_Root_CA_X3.crt
``

When update that line on my virtual machine to match that `!mozilla/DST_Root_CA_X3.crt` then `apt-get update && apt-get install ca-certificates` and reboot it is working again.

What is going on here? Why did it suddenly start failing yesterday on my VM? Why is Ubuntu on the VM different and more strict?

Источник

0

1

openssl s_client -showcerts -connect incust.com:443 </dev/null | openssl x509 -noout -dates
depth=0 C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
verify error:num=18:self signed certificate
verify return:1
depth=0 C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
verify error:num=10:certificate has expired
notAfter=Nov 12 12:46:03 2014 GMT
verify return:1
depth=0 C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
notAfter=Nov 12 12:46:03 2014 GMT
verify return:1
DONE
notBefore=Oct 13 12:46:03 2014 GMT
notAfter=Nov 12 12:46:03 2014 GMT

openssl s_client -showcerts -connect incust.com:443 </dev/null | openssl x509 -noout -dates
depth=0 C = UA, ST = Kiev, L = Kiev, O = Hosting Ukraine LLC, OU = IT Department, CN = ssl.hosting-admin.net, emailAddress = abuse@ukraine.com.ua
verify error:num=18:self signed certificate
verify return:1
depth=0 C = UA, ST = Kiev, L = Kiev, O = Hosting Ukraine LLC, OU = IT Department, CN = ssl.hosting-admin.net, emailAddress = abuse@ukraine.com.ua
verify error:num=10:certificate has expired
notAfter=Sep  9 14:39:52 2016 GMT
verify return:1
depth=0 C = UA, ST = Kiev, L = Kiev, O = Hosting Ukraine LLC, OU = IT Department, CN = ssl.hosting-admin.net, emailAddress = abuse@ukraine.com.ua
notAfter=Sep  9 14:39:52 2016 GMT
verify return:1
DONE
notBefore=Sep 10 14:39:52 2015 GMT
notAfter=Sep  9 14:39:52 2016 GMT

Вот что пишет curl:

curl --ssl https://incust.com -v
* Rebuilt URL to: https://incust.com/
*   Trying 192.99.62.181...
* TCP_NODELAY set
* Connected to incust.com (192.99.62.181) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, Client hello (1):
curl: (60) SSL certificate problem: unable to get local issuer certificate

В чем может быть проблема? Какие еще данные нужны для отладки?

Источник

I’ve installed Landscape on a new install of Ubuntu 16.04, and I am trying to register clients with it. We have created a CA and signed our certificate (https://help.landscape.canonical.com/LDS/SSL). We also added the certificate to the trusted certificates on the client.

Now we try to connect our client (Ubuntu 16.04) to the Server with the following command:

sudo landscape-config --computer-title "Agent" --account-name standalone  --url https://landskap/message-system --ping-url http://landskap/ping --ssl-public-key=/etc/ssl/certs/landscape_server_ca.pem

After the configuration dialog this error message appears:

The server’s SSL information is incorrect, or fails signature verification!
If the server is using a self-signed certificate, please ensure you supply it with the —ssl-public-key parameter.

Yes our server is called ‘Landskap’…

We’ve checked on the client, if there is any additional information in /var/log/landscape/broker.log and found the following error entry.

PyCurlError: Error 60: server certificate verification failed. CAfile: /usr/local/share/ca-certificates/landscape_server_ca.crt CRLfile: none
2017-04-18 14:08:38,978 ERROR    [MainThread] Message exchange failed: server certificate verification failed. CAfile: /usr/local/share/ca-certificates/landscape_server_ca.crt CRLfile: none
2017-04-18 14:08:38,978 INFO     [MainThread] Message exchange failed.
2017-04-18 14:08:38,979 INFO     [MainThread] Message exchange completed in 0.17s.
2017-04-18 14:09:38,982 INFO     [MainThread] Starting urgent message exchange with https://landskap/message-system.
2017-04-18 14:09:39,149 ERROR    [PoolThread-twisted.internet.reactor-0] Error contacting the server at https://landskap/message-system.
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/landscape/broker/transport.py", line 71, in exchange
    message_api)
  File "/usr/lib/python2.7/dist-packages/landscape/broker/transport.py", line 45, in _curl
    headers=headers, cainfo=self._pubkey, curl=curl))
  File "/usr/lib/python2.7/dist-packages/landscape/lib/fetch.py", line 109, in fetch
    raise PyCurlError(e.args[0], e.args[1])

Please help us

Источник