is it the cert, the chain, or the clock? a tls whodunit

certificateshttpstls6 replies 路 236 views 路 started
  1. help!! we renewed the certificate on our internal API yesterday. on my desktop browser everything looks fine. but curl now fails with:

    Your connection is not private

    Your connection is not private
    Attackers might be trying to steal your information from portal.example.org
    (for example, passwords, messages, or credit cards).
    NET::ERR_CERT_DATE_INVALID
    

    the certificate isn't expired, the name matches... nothing else changed, why would only some clients complain?

    ive checked the dates, teh hostname and teh issuer... everything looks correct when i click the padlock in my browser... im clearly missing something, but i dont know what tool shows what the client actually receives.

    2
  2. is teh a spreadsheet web app certificate from a public CA or an internal one?

    3 0 helpful
  3. oh ive been there lol java and Python clients use their own trust stores 馃槀 java uses cacerts in the JRE; Python requsets uses teh certifi bundle. If the root is new or private, those stores need updating even when teh OS trusts it. lmk how it goes

    0 6 helpful
  4. check the order. some servers send the intermediate before the leaf or include an old intermediate from a previous CA. openssl s_client output shows s: (subject) and i: (issuer) for each certificate; each isuser must be teh next subject. hope that helps :)

    lol

    0 2 helpful
  5. hmmmm not sure about that id add an automated chain check to moniotring. An external TLS scan after every renewal would have caught this before customers did. but hey ymmv

    facepalm

    13 2 helpful
  6. been there man pro tip: write down what u change... i didnt and had to redo https from scratch. @tinynomad-2kl did u ever fix it? worked for me anyway 馃し

    0 4 helpful

Reply to this topic

Sign in or create an account to reply.