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”).

1 Like

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 …


FYI, I’m seeing again the “Unacceptable TLS certificate” error message today, using Pamac to make the last Stable update…

Pamac also just telling my Error: Failed to synchronize databases.

Have patience. It will update it at some point in the future.

That’s a different error than the AUR database.

Okay, but after clicking “refresh data base” in the top right menue, it updates and then another error shows up and it said Error: “Failed to synchronize AUR database”.

So it looks to me, this errors are linked somehow.

1 Like

No, the errors have nothing in common, and you either experienced a temporary downtime of your internet connection or connectivity to your selected mirror. However, it’s by chance and not a bug.

1 Like

No need to tell me to be patient, I know that It will update sooner or later… As matter of fact, it just did.
I was just replying to the request of @philm to let the team know if this issue is solved or not:

Hi, you can use the following command :

gnutls-cli --tofu


Processed 159 CA certificate(s).
Resolving ''...
Connecting to '2a02:6ea0:c900::10:443'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
 - subject `', issuer `CN=R3,O=Let's Encrypt,C=US', serial 0x04d5f8629c5f36e95639a4888de7eef5acec, EC/ECDSA key 256 bits, signed using RSA-SHA256, activated `2023-02-16 13:00:05 UTC', expires `2023-05-17 13:00:04 UTC', pin-sha256="wWjxTRsdI+HGgYasYZwhHHl2xIdgRXqLsi6IF1zGeFg="
	Public Key ID:
	Public Key PIN:

- Certificate[1] info:
 - subject `CN=R3,O=Let's Encrypt,C=US', issuer `CN=ISRG Root X1,O=Internet Security Research Group,C=US', serial 0x00912b084acf0c18a753f6d62e25a75f5a, RSA key 2048 bits, signed using RSA-SHA256, activated `2020-09-04 00:00:00 UTC', expires `2025-09-15 16:00:00 UTC', pin-sha256="jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0="
- Certificate[2] info:
 - subject `CN=ISRG Root X1,O=Internet Security Research Group,C=US', issuer `CN=DST Root CA X3,O=Digital Signature Trust Co.', serial 0x4001772137d4e942b8ee76aa3c640ab7, RSA key 4096 bits, signed using RSA-SHA256, activated `2021-01-20 19:14:03 UTC', expires `2024-09-30 18:14:03 UTC', pin-sha256="C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M="
|<1>| There is a newer OCSP response but was not provided by the server
- Status: The certificate is NOT trusted. The revocation or OCSP data are old and have been superseded. 
*** PKI verification of server certificate failed...
Host (https) has never been contacted before.
Its certificate is valid for
Are you sure you want to trust it? (y/N): y

just :

The revocation or OCSP data are old and have been superseded. 

or be patient

I was also having this problem and I tried the various suggestions on this thread but none worked. I then tried to su as root and run the command and that worked so maybe someone else could try that and see if it resolves the issue.

pamac update

Happened here in testing and unstable. Noticed no problem in stable.

> cp: cannot create regular file '/var/tmp/pamac/dbs/sync/core.db': Permission denied                                                         
> cp: cannot create regular file '/var/tmp/pamac/dbs/sync/extra.db': Permission denied

command: pamac update --aur

I had that the other day on stable, I solved it by running sudo pacman -Syyu and then pamac upgrade -a

This specific error is only an issue when you have the option for checking AUR script updates in Pamac.

It does not matter what your branch is - the aur database is the same.

Avoid the issue all-together by disabling the Pamac AUR check


It is well known that combining the system update with an AUR rebuild may and likely will cause serious headaches. Just search the forum - there is countless issues on this.

Use a helper script like [root tip] [HowTo] Check if your AUR build scripts have been updated

The intro to that post has had me confused for a long time, I’m not a programmer, I only know what I have learned through my way, but I interpret this as if you are on stable branch you should never use aur. Or am I missing something here??

if [[ $(pacman-mirrors -G) == 'stable' ]]; then echo 'AUR is a no-go'; else echo 'OK - go ahead'; fi