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 aur.manjaro.org:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' > acm.pem
❯ openssl s_client -connect aur.manjaro.org:443 -showcerts </dev/null 2>/dev/null > chain.pembundle
❯ openssl x509 -noout -ocsp_uri -in acm.pem
http://r3.o.lencr.org
❯ 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:
04106AA116A174204D99F734376D1C4BF611
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 | 7.1.3.2.1 | CAs MUST NOT sign OCSP responses using the SHA-1 hash algorithm. |
Simon B, [27.02.23 16:10]
https://cabforum.org/2022/01/26/ballot-sc53-sunset-for-sha-1-ocsp-signing/
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
- CDN_EU_MAIN_DOWNLOADS 473 TB
- CDN_EU_MANJARO_REPO 26.7 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
Responses:
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
Extensions:
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 …
3 Likes
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 aur.manjaro.org
so…
Processed 159 CA certificate(s).
Resolving 'aur.manjaro.org:443'...
Connecting to '2a02:6ea0:c900::10:443'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
- subject `CN=1715854792.rsc.cdn77.org', 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:
sha1:6b2931e168a1b5af70a286272fcbacb4d9054eb6
sha256:c168f14d1b1d23e1c68186ac619c211c7976c48760457a8bb22e88175cc67858
Public Key PIN:
pin-sha256:wWjxTRsdI+HGgYasYZwhHHl2xIdgRXqLsi6IF1zGeFg=
- 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 aur.manjaro.org (https) has never been contacted before.
Its certificate is valid for aur.manjaro.org.
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.
su
pamac update
Hi
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