A couple of things to check for apikey.pub accessibility:
-
The /.well-known/amphtml/apikey.pub
file is accessible to both mobile and desktop user agents (e.g no redirect for non-mobile as the AMP cache client may redirect)
-
The public key is not excluded in robots.txt e.g:
User-agent: *
Allow: /.well-known/amphtml/apikey.pub
- The public key response has the expected headers (e.g content-type: text/plain):
curl -I https://amp.example.com/.well-known/amphtml/apikey.pub
HTTP/2 200
date: Sun, 26 Jul 2020 23:48:55 GMT
content-type: text/plain
vary: Accept-Encoding
etag: W/"1c3-173478a8840"
last-modified: Sun, 26 Jul 2020 23:48:55 GMT
With those things in place, I get an “OK” success response from the update/cache endpoint

I’ve been trying to update the AMP cached pages on my website for a couple of days now to no avail.
While the documentation for updating the cache exists, it was probably written by a Google engineer, and as a result, isn’t the easiest read.
https://developers.google.com/amp/cache/update-cache
I’ve followed the directions to the best of my ability.
I’ve created a private-key and public-key. Created a signature.bin and verified it using the procedure in Google’s own documentation.
~$ openssl dgst -sha256 -signature signature.bin -verify
public-key.pem url.txt
Verified OK
The public-key.pem has been renamed to apikey.pub and uploaded to the following directory:
https://irecover.ca/.well-known/amphtml/apikey.pub
To validate that there has been no issue in the copying, I checked the signature using the following:
$ openssl dgst -sha256 -signature signature.bin -verify <(curl https://irecover.ca/.well-known/amphtml/apikey.pub) url.txt
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left Speed
100 450 100 450 0 0 2653 0 –:–:– –:–:–
–:–:– 2662
Verified OK
Now I convert the signature file to base64 and replace the / with _ and the + with –
cat signature.bin | base64 > signature.b64
sed ‘s///_/g’ signature.b64 > signature.b64a
sed ‘s/+/-/g’ signature.b64a > signature.b64b
sed ‘s/=//g’ signature.b64b > signature.b64c
cat signature.b64c | tr -d ‘n’ > signature.b64
I have made a script that makes the update-cache url for me. It also creates a timestamp right that moment and uses it for the amp_ts variable (So the amp_ts is never out by more than 1 second). I then append that to the end of the query which is about to be cURL’d by the script I have made, so it looks like so:
https://irecover-ca.cdn.ampproject.org/update-cache/c/s/irecover.ca/article?amp_action=flush&_ts=1581446499&_url_signature=KDaKbX0AbVbllwkTpDMFPOsFCRNw2sbk6Vd552bbG3u5QrecEmQ1SoMzmMR7iSXinO7LfM2bRCgJ1aD4y2cCayzrQuICrGz6b_PH7gKpo6tqETz06WmVeiP89xh_pBOu-pyN5rRHf0Pbu8oRkD2lRqgnGrLXDfIrFTTMRmHlO0bsa8GknyXL8RNXxk9ZQaufXAz-UJpoKaZBvT6hJWREAzxoZ-rGnDPVaC3nlBCu3yPorFcTbbr0CBz2svbfGgAYLQl54lLQmUpxI8661AEe1rdOLqAyLIUb4ZiSbO65-PmIkdZWVPFHMdbpSv4GMNdvodleCWBfMAcG2C09v-LR6g
However, this always results in the same error code from google.
Invalid public key due to ingestion error: 404 or 410 error from origin
Does anyone have any idea what I’m doing wrong?
They ask to serve the key with the content-type “text/plain” in the Guidelines section in the docs you provide. Maybe this is important for them for some reason. You serve your key without content-type. You can check this in Network panel in your browser.
@JamesGray did changing the content-type help you? I and many others online seem to be struggling with this topic. In my case at least I have set the content-type
Hi, is it solved? I was also confused about cache update and got good idea from bug reported over amphtml repo here is link –