Score:0

Pagespeed cannot always access page (FAILED_DOCUMENT_REQUEST), SSL certification error?

in flag

I found that Google cannot access my page (this is a follow up of https://webmasters.stackexchange.com/questions/137407/page-cannot-be-crawled-by-google-at-all)

Now I am thinking it might be a server configuration error.

I am using Letsencrypt certbot and the cloudflare-dns plugin to obtain a wildcard certificate. The page can be accessed just fine in Google Chrome and Firefox, but for example PageSpeed Insights shows the following problem:

Lighthouse returned error: FAILED_DOCUMENT_REQUEST. Lighthouse was unable to reliably load the page you requested. Make sure you are testing the correct URL and that the server is properly responding to all requests. (Details: net::ERR_TIMED_OUT) You may refresh to try again.

I ran testssl and it shows a certificate chain error:

Chain of trust NOT ok (expired)

Here is the full output:

$ docker run --rm -ti  drwetter/testssl.sh -S page.et

###########################################################
    testssl.sh       3.1dev from https://testssl.sh/dev/

      This program is free software. Distribution and
             modification under GPLv2 permitted.
      USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

       Please file bugs @ https://testssl.sh/bugs/

###########################################################

 Using "OpenSSL 1.0.2-chacha (1.0.2k-dev)" [~183 ciphers]
 on 06919ea62e34:/home/testssl/bin/openssl.Linux.x86_64
 (built: "Jan 18 17:12:17 2019", platform: "linux-x86_64")


 Start 2021-11-07 13:51:34        -->> 49.12.225.98:443 (page.et) <<--

 rDNS (49.12.225.98):    static.98.225.12.49.clients.your-server.de.
 Service detected:       HTTP


 Testing server defaults (Server Hello) 

 TLS extensions (standard)    "renegotiation info/#65281" "server name/#0" "EC point formats/#11" "supported versions/#43" "key share/#51" "supported_groups/#10"
                              "max fragment length/#1" "application layer protocol negotiation/#16" "extended master secret/#23"
 Session Ticket RFC 5077 hint no -- no lifetime advertised
 SSL Session ID support       yes
 Session Resumption           Tickets no, ID: yes
 TLS clock skew               Random values, no fingerprinting possible 
 Client Authentication        none
 Signature Algorithm          SHA256 with RSA
 Server key size              RSA 2048 bits (exponent is 65537)
 Server key usage             Digital Signature, Key Encipherment
 Server extended key usage    TLS Web Server Authentication, TLS Web Client Authentication
 Serial / Fingerprints        03561169DAC4AE4390C247FEAF565BEA91E9 / SHA1 E8D7A5C68364F801574FFEEF5ECDF7C2CBE0A744
                              SHA256 2B9EB3495C170111F7746CAA6C0D4607A88888631529F48ECFDCC5E916369BB7
 Common Name (CN)             page.et 
 subjectAltName (SAN)         *.page.et page.et 
 Trust (hostname)             Ok via SAN and CN (same w/o SNI)
 Chain of trust               NOT ok (expired)
 EV cert (experimental)       no 
 Certificate Validity (UTC)   89 >= 30 days (2021-11-07 12:49 --> 2022-02-05 12:49)
 ETS/"eTLS", visibility info  not present
 Certificate Revocation List  --
 OCSP URI                     http://r3.o.lencr.org
 OCSP stapling                not offered
 OCSP must staple extension   --
 DNS CAA RR (experimental)    not offered
 Certificate Transparency     yes (certificate extension)
 Certificates provided        3
 Issuer                       R3 (Let's Encrypt from US)
 Intermediate cert validity   #1: ok > 40 days (2025-09-15 16:00). R3 <-- ISRG Root X1
                              #2: ok > 40 days (2024-09-30 18:14). ISRG Root X1 <-- DST Root CA X3
 Intermediate Bad OCSP (exp.) Ok



 Done 2021-11-07 13:51:45 [  12s] -->> 49.12.225.98:443 (page.et) <<--

SSL Labs shows two chains, one with the expired Letsencrypt Root:

https://www.ssllabs.com/ssltest/analyze.html?d=page.et

SSL Labs: EXPIRED root

But it still shows "grade A".

Is this a server configuration issue? I basically just setup a standard Aapache and used certbot (v1.21.0) to set-up SSL. I did not make any changes to the SSL configuration.

EDIT

I tried

# tcpdump "port 443"

In the case PageSpeed shows a timeout, I do not see a single byte of traffic in tcpdump.

But I also checked with isitdownrightnow.com/page.et.html and downforeveryoneorjustme.com/page.et -> they all show it's up (and I see traffic in tcpdump then)

EDIT:

In the dev tools when running page speed I see the request

 Request URL: https://www.googleapis.com/pagespeedonline/v5/runPagespeed?key=AIzaSyAwlPiPJIkTejgqqH01v9DmtPoPeOPXDUQ&locale=en_US&url=https%3A%2F%2Fpage.et%2F&strategy=mobile

failing with:

  message: "Lighthouse returned error: FAILED_DOCUMENT_REQUEST. Lighthouse was unable to reliably load the page you requested. Make sure you are testing the correct URL and that the server is properly responding to all requests. (Details: net::ERR_TIMED_OUT)"
djdomi avatar
za flag
already checked the logs of the Webservers?
in flag
Yes, no 500 response codes, no errors
djdomi avatar
za flag
there must be an error log entry on apache if error logging is enabled. either your directory has bad access for thw www user or similar
in flag
I get the error only in around 50% of the cases. Often the mobile tab shows a result, the desktop tab doesn't or the other way around. When I get a timeout on both tabs, there was not a single log message. When I get results, just normal access log entries (200, and a 404 for some Javascript)
in flag
In the browser I don't get any error at all .. not sure if it is some routing problem to the data center that runs pagespeed ...
in flag
I also checked with https://www.isitdownrightnow.com/page.et.html and https://downforeveryoneorjustme.com/page.et -> they all show it's up
djdomi avatar
za flag
have you used the developer mode on most browsers is enabling by pressing F12
in flag
I believe Google is trying to make the connection to my server, not my browser? But I will try
in flag
Edited the question.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.