Some extra logging output from Chrome and Chrome Canary on Mac

Chrome Mac (Version 58.0.3029.81 (64-bit))

[30598:110595:0426/122758.584314:WARNING:cert_verify_proc_mac.cc(142)] Unknown error mapped to CERT_STATUS_INVALID: Error Domain=NSOSStatusErrorDomain Code=-2147408893 "(null)" (-2147408893)
[30598:110595:0426/122758.584437:WARNING:cert_verify_proc_mac.cc(142)] Unknown error mapped to CERT_STATUS_INVALID: Error Domain=NSOSStatusErrorDomain Code=-2147409644 "(null)" (-2147409644)


Chrome Canary Mac (Version 60.0.3080.5 (Official Build) canary (64-bit))

[30955:30979:0426/122912.384422:WARNING:cert_verify_proc_mac.cc(142)] Unknown error mapped to CERT_STATUS_INVALID: Error Domain=NSOSStatusErrorDomain Code=-2147408893 "(null)" (-2147408893)
[30955:30979:0426/122912.384534:WARNING:cert_verify_proc_mac.cc(142)] Unknown error mapped to CERT_STATUS_INVALID: Error Domain=NSOSStatusErrorDomain Code=-2147409644 "(null)" (-2147409644)


When testing on Chrome for Windows (Version 56.0.2924.87 (64-bit) and Version 58.0.3029.81) the certificate works as expected.

I'm not able to reproduce this on my machine, though I'm on 10.12, not 10.11. Could you attach a net-internals log per https://dev.chromium.org/for-testers/providing-network-details? Thanks!

Yep - no problem - please see attached.

Deleted: chrome-net-export-log.json 835 KB

chrome-net-export-log.json 835 KB View Download

Ah - note that I used net-export as apparently net-internals is being deprecated... is that OK or would you prefer net-internals?

Thank you for providing more feedback. Adding requester "davidben@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Yeah, net-export is fine. We need to update those instructions... :-)

(Leaving this for certificate folks to look at. I'm not very familiar with that end of the stack.)

I can't reproduce (works fine for me).

The error code given in comment #2 from the log doesn't map to anything, so not sure what is going wrong. Maybe a problem with the system verifier? Although you said it works in Safari right?

Can you try disabling your chrome extensions (like taper monkey) and seeing if it changes anything? (I don't think it will make a difference, but worth ruling out).

Good idea... but no luck.

I opened an incognito window and got the same response (I'm 99.9% sure incognito mode disables all extensions, right?)

And yes - Safari works fine.

One thing I will test is to disable my manually-added trusted Certificate Authorities from my keystore and see if that makes any difference.

Yep - I've removed those trusted CAs from my keychain, and no difference.  Also tested on a colleague's Mac (same Chrome; same OSX version) and sees the same issue.

@mattm: Does the log in comment #2 mean anything to you?

I am testing on Mac 10.12.4 and can't reproduce - whereas the bug filer is running 10.11.6. Best guess is this is specific to that version of OS X.

Incidentally, I have been using self-signed certificates for a while; I recently wanted to use Subject Alternate Names in my self-signed certificates which necessitated generating v3 certs, rather than v1 certs.

My v1 certs have always worked fine with Chrome, for example:  https://esxi.home.andrewdicks.co.uk/

It's only since changing certs to v3 that I've seen this issue.

I believe it's because your leaf cert is marked a CA cert (CA:TRUE). I seem to recall that newer versions of macOS actively reject that as an invalid cert unless it's a self-signed cert.

I'd check that :)

FWIW, I tested https://jira.home.andrewdicks.co.uk/ on a few macOS versions:
10.9: INVALID_CERT
10.11: INVALID_CERT
10.12: CERT_AUTHORITY_INVALID

rsleevi's comment about the basicConstraints CA:TRUE in #17 sounds reasonable, so I didn't dig in any further. Try fixing that and let us know if it resolves the problem.


Also, note re comment #16:
 https://esxi.home.andrewdicks.co.uk/ is marked as a v1 certificate, but actually does have extensions(including SAN), this is invalid, and it fails on chrome canary.

...... damn.  You guys are good!  Thanks.  I had simply cloned the v3_ca section with CA:true.  When I changed that to CA:false, it started working as expected

And yes - I realised that I'd put SAN extensions in the v1 certs, and they weren't valid, hence changing to v3... but I'd foolishly copy&pasted the v3_ca section from the CA openssl.conf

Thanks again for your detailed help with this.  Really impressive.

Thank you for providing more feedback. Adding requester "mattm@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Just in case anyone ever sees this in the future, a better fix for my leaf certificate was to not use the v3_ca section at all for signing (kinda obviously, when I thought about its name)... instead, I created an extensions section entitled server_cert, and set extensions that were more meaningful for server certificates rather than CAs:

[ server_cert ]
# Extensions for server certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

I've also checked that certificates signed like this work fine in Chrome Canary too.

Thanks again for all the assistance.