Pamac fails to synchronise due unacceptable TLS certificate

i still can’t update help
i’m on testing branch

Only patience will bring you peace (and updates).

1 Like

The certificates are valid. We even switched to the official LetsEncrypt CDN77 provides. The actual issue is OCSP signing with sha1sums, which is not recommended anymore:

Simon B, [27.02.23 15:33]
it is funny, wget throws the same error where as curl works fine

Simon B, [27.02.23 15:58]
❯ openssl s_client -connect 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' > acm.pem
❯ openssl s_client -connect -showcerts </dev/null 2>/dev/null > chain.pembundle
❯ openssl x509 -noout -ocsp_uri -in acm.pem
❯ openssl ocsp -issuer chain.pembundle -cert acm.pem -text -url $(openssl x509 -noout -ocsp_uri -in acm.pem)
OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: 48DAC9A0FB2BD32D4FF0DE68D2F567B735F9B3C4
          Issuer Key Hash: C257C8A3E9D3C48E991D792814211B21F214FA78
          Serial Number: 04D5F8629C5F36E95639A4888DE7EEF5ACEC
    Request Extensions:
        OCSP Nonce: 
Responder Error: unauthorized (6)

Simon B, [27.02.23 16:00]
problem seems to be that they use SHA1 instead of SHA-256

Simon B, [27.02.23 16:09]
@philmmjr so it seems CDN77 needs to change the settings on their ocsp server

Simon B, [27.02.23 16:09]
| 2022-06-01 | | CAs MUST NOT sign OCSP responses using the SHA-1 hash algorithm. |

Simon B, [27.02.23 16:10]

We reported that issue to CDN77 and wait for a fix. Also not always the issue will happen on your end. You can try it again at a later timeslot. Most likely it will download the AUR database at some point.

Alternatively, use an AUR helper that uses the official AUR DB to once in a while check for AUR update, otherwise, use Pamac or Pacman to update official packages.

Well, here are the current stats of the last 30 days on traffic processed thru CDN77:

  • CDN_EU_AUR_DB 27.9 TB

Yeah that’s a lot of load removed from the AUR servers, but if it doesn’t work it doesn’t work (OK, it MIGHT work at some point, but people don’t want to update “at some point”, they want to update “now”).

Seems LetsEncrypt support only SHA1 on their CERTID as signing as mentioned by the CDN77 support:

Thanks a lot for your patience.
Ive checked the matter extensively with our admins. The hash algorithm that is used for the OCSP response itself, provided from the OCSP server is not under our control. It’s rather controlled by Let’s Encrypt. Our edge servers only do the OCSP check and “staple” the response from the OCSP server (specified in the certificate) to our response to the client.
You can check more details in this thread for example which give some info about why LE in particular uses SHA-1 uniquely: OCSP Responder support for SHA2 hashes in CertID - Issuance Tech - Let's Encrypt Community Support

So the only workaround would be to use curl instead the native functions of libsoup.

Here is another update on the matter:

Simon B, [17.03.23 18:18]
OCSP Response Information:
  Response Status: Successful
  Response Type: Basic OCSP Response
  Version: 1
  Responder ID: CN=R3,O=Let's Encrypt,C=US
  Produced At: Fri Mar 17 09:18:00 UTC 2023
    Certificate ID:
      Hash Algorithm: SHA1
      Issuer Name Hash: 48dac9a0fb2bd32d4ff0de68d2f567b735f9b3c4
      Issuer Key Hash: 142eb317b75856cbae500940e61faf9d8b14c2c6
      Serial Number: 04d5f8629c5f36e95639a4888de7eef5acec
    Certificate Status: good
    This Update: Fri Mar 17 09:00:00 UTC 2023
    Next Update: Fri Mar 24 08:59:58 UTC 2023
  Signature Algorithm: RSA-SHA256

Simon B, [17.03.23 18:19]
The problem was the Signature Algorithm, not the Hash Algorithm

Simon B, [17.03.23 18:23]
So pamac correctly didn't accepted a SHA-1 signing and had an error. Now it comes with RSA-SHA256 which is accepted

Philip M, [17.03.23 18:44]
So the new certs fixed it?

Simon B, [17.03.23 18:47]
could be an update on the ocsp server, since they sign the request

So let us know if you still have issues with this …