Pixelsrv-tls on Mac - Pixelserv cert trusted yet still prompted

[Ramias]

Greetings oh great ones

I have Pixelsrv (running as part of AB-Solutions 3.0) and have generated the root ca cert from the router and imported it on my Mac per https://github.com/kvic-z/pixelserv-tls (booted mac into recovery mode, disabled System Integrity Protection etc).

Still no luck.

In my Mac Keychain the Pixelsrv CA cert shows up under system roots and when I click on it, it is set to Always Trust for everything.

Yet when I go to many web sites where blocked ads are attempted to be served via SSL, Safari will throw an alert box showing me that *.whatever.com is not trusted (i.e. the cert is not from a trusted source). I don't get this on every site (probably because not every site is serving via SSL) bit I get it on quite a few.

Any ideas what to do here?

Thanks

 

[kvic]

Looks like your root CA certificate was not properly generated. You can do diagnosis here by first making sure the root CA cert used by pixelserv-tls is valid and the same cert is imported into OS X. Look into the router's syslog for any errors showing pixelserv-tls fails to load or use the root CA cert. You can also go to http://doubleclick.net/servstats and check what are the values of the SSL related counters. Their mnemonics are SLH, SLM, SLE and SLU. Make sure first pixelserv-tls is running well with the generated certificates.

 

[Ramias]

Thanks

This is what my stats look like:

slh 47063 # of accepted HTTPS requests
slm 247 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slu 253 # of dropped HTTPS requests (unknown error)

I checked the keyboard buffer on my router and i copied/pasted the commands straight from the pixelsrv-tls GitHub site here:

https://github.com/kvic-z/pixelserv-tls

And the Pixelserv CA cert shows as a Root Certificate Authority on my OS X keychain.

And I stopped/Restarted pixelsrv.

This is what my syslog looks like:

Dec 6 18:26:59 Ramias: Started pixelserv-tls (AB-Solution) from .
Dec 6 18:26:59 pixelserv[27376]: pixelserv-tls version: v35.HZ12.Ki compiled: Oct 31 2016 11:29:48 options: 192.168.0.2 -l
Dec 6 18:26:59 pixelserv[27376]: Listening on :192.168.0.2:80
Dec 6 18:26:59 pixelserv[27376]: Listening on :192.168.0.2:443
Dec 6 18:27:56 pixelserv[27636]: ( 4) 192.168.0.12: edge.quantserve.com GET /quant.js HTTP/1.1
Dec 6 18:27:56 pixelserv[27637]: ( 4) 192.168.0.12: keisu02.eproof.com GET /js/v20100407.js HTTP/1.1
Dec 6 18:27:56 pixelserv[27638]: (14) 192.168.0.12: widget.quantcast.com GET /p-e2qh6t-Out2Ug/10 HTTP/1.1 secure
Dec 6 18:28:08 pixelserv[27642]: sb.monetate.net _.monetate.net missing
Dec 6 18:28:10 pixelserv[27378]: cert _.monetate.net generated and saved
Dec 6 18:28:11 pixelserv[27647]: (14) 192.168.0.12: sb.monetate.net GET /js/1/a-d0156d0b/p/marriott.com/411408/g HTTP/1.1 secure
Dec 6 18:28:14 pixelserv[27651]: (14) 192.168.0.12: sb.monetate.net GET /js/1/a-d0156d0b/p/marriott.com/411408/g HTTP/1.1 secure
Dec 6 18:28:19 pixelserv[27652]: (15) 192.168.0.12: gscounters.us1.gigya.com GET /gscounters.sendReport?reports=%.....dk=js_6.5.23&format=jsonp&callback=gigya._.apiAdapters.web.callback&co
Dec 6 18:28:26 pixelserv[27676]: ak1s.abmr.net _.abmr.net missing
Dec 6 18:28:28 pixelserv[27378]: cert _.abmr.net generated and saved
Dec 6 18:28:31 pixelserv[27761]: (14) 192.168.0.12: g.symcd.com GET /MEkwR......K4PlXywJcRE6AHIAIDAjqS HTTP/1.1
Dec 6 18:29:10 pixelserv[27786]: (14) 192.168.0.12: g.symcd.com GET /MEkwR6ADAgEAMEAwPjA8M......HIAIDAjqS HTTP/1.1
Dec 6 18:31:19 pixelserv[27881]: ( 4) 192.168.0.12: edge.quantserve.com GET /quant.js HTTP/1.1
Dec 6 18:31:19 pixelserv[27882]: ( 4) 192.168.0.12: keisu02.eproof.com GET /js/v20100407.js HTTP/1.1

 

[kvic]

Both the stats and the log show pixelserv is working well. Do you see correlation between error in Safari and missing cert in the log? If they do the timestamps should be very close. Also, do you see error by going to https://doubleclick.net/servstats ? If you do, can you click on the padlock in Safar address bar and show the detail of the certificate, and any hierarchy of security credentials i.e. double click.net's cert is one level below pixelserv's root CA cert?

Cheers

 

[Ramias]

Ok this is interesting. the https://doubleclick.net cert is fine.

It has a "not valid before" of this morning. I restarted the pixelserv-tls service last night when I cycled ab-solutions (stopping/starting ab-solutions also restarted pixelserv-tls).

Other certs are still having issues. One I see right now has a "not valid before" of Sunday Nov 27th (when I first installed Pixelserv.

When I ran the commands to generate the ca.crt, I never restarted pixelserv after that. I thought those commands were to just export the root CA, not generate it.

I went to /opt/var/cache/pixelserv and deleted every cert except the ca.crt and ca.key and now (fingers crossed) things seem to be working. I can see new certs generated there for domains that were giving me problems before.

Thanks

 

[thelonelycoder]

It has a "not valid before" of this morning. I restarted the pixelserv-tls service last night when I cycled ab-solutions (stopping/starting ab-solutions also restarted pixelserv-tls).

Switching ad-blocking off and back on does this, PS is logically disabled when ad-blocking is off.
However, the (ps) menu has an option to only turn pixelserve-tls off or on, a less intrusive action, although it converts the blocking IP in hosts-adblock as well as the blacklist.txt to either 0.0.0.0 or the PS IP shown in the AB-Solution UI.

When I ran the commands to generate the ca.crt, I never restarted pixelserv after that. I thought those commands were to just export the root CA, not generate it.

If you originally installed pixelserv-tls with the (ps) option, those certs were auto-generated during the install process.
If you then regenerate the certs manually and replace the existing ones, pixelserv-tls likely needs to restart to read the new certs in. Hence your errors.

I went to /opt/var/cache/pixelserv and deleted every cert except the ca.crt and ca.key and now (fingers crossed) things seem to be working. I can see new certs generated there for domains that were giving me problems before.

That totally makes sense if you did as I described above, these certs are not valid against the manually new generated PS certs and therefore are not seen as valid. Your browser rightly shows an error for that.