@flaxking said in SSL/TLS client certificates questions: Domain name doesn't matter, unless you're signing with a public CA. I'd think self-signed vs internal CA vs public CA would depend on what the authentication mechanism supports and how you have to manage the certificates. (i.e. if there are going to be a ton of them it might be easier for the authentication mechanism just to trust certificates signed by a certain internal CA rather than having to make each certificate trusted. From what I've seen so far, I've come to the same conclusion.

Got it all working. Thanks for everyone's assistance!

Circling back to GPP. Thanks to @FiyaFly , who was able to help me out with the syntax for the fields. Do not use quotes in the target or start in paths. Target Path: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe Arguments: --incognito --proxy-server=squid1.domain.com:3128 --user-data-dir="%LOCALAPPDATA%\Google\Squid1\User Data" Start in: C:\Program Files (x86)\Google\Chrome\Application\ I also used the create option and desktop (standard, not all users desktop).

Updating this thread. I ended up setting up the squid.conf file with the following config to get it to work. First, at the top of the localnet lines- acl localnet src 205.205.205.1/32 Then, I added the only domains that I wanted to provide access to. This whitelisted them. acl GOOD dstdomain .google.com acl Good dstdomain .domain.ca Followed by, the allow and deny lines http_access allow GOOD http_access deny all Finally, "uncommenting" the Safe ports/services for 80 and 443.

@scottalanmiller said in NGinx Configuration Block for Zimbra Reverse Proxy: Someone was looking for this specifically so... server { client_max_body_size 80M; server_name my.domain.com; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_set_header X-NginX-Proxy true; proxy_redirect off; location / { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_set_header X-NginX-Proxy true; proxy_pass https://myip:443/; proxy_redirect off; # Socket.IO Support proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } listen 80; ssl_stapling on; ssl_stapling_verify on; ssl_session_cache shared:SSL:10m; add_header Strict-Transport-Security "max-age=31536000; includeSubdomains"; listen 443 ssl; # managed by Certbot ssl_certificate /etc/letsencrypt/live/my.domain.com/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/my.domain.com/privkey.pem; # managed by Certbot include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot } Remember to create one for the Admin console on port 7071.

@emad-r said in Proxies as VPN?: @emad-r They are using reverse proxy squid on a PFsense router as VPN. or to access company resources. For example, I think they made LAN 7.7.7.* and put company resource like http://web/company and only 7.7.7.* can access it in the config on PFsense. It does not work 100% of course. As you can bypass it if you do http://web/company?32141 and access it from WAN That works only if the resources are web only. In which case, a VPN was never appropriate in the first place. So in this case, a VPN would actually allow you to access unpublished web resources. But the reverse proxy will publish them. Now the presumed difference to most people is that the VPN will add a layer or protection in the form of authentication, and the proxy will not. This is not correct, however, because you can add that to the proxy, too. So, in reality, you are correct, in this specific case, the reverse proxy is actually making a VPN for just those specific web resources. It's a special case VPN, assuming you are using it as an SSL point.

@wrx7m that vendor sounds like GE or UTC. These companies employ the most ridiculous procedures and requirements in the name of security. I think it all comes down from gov oversight, so dumbasses on top audit you, then you need to implement some retarded procedure that does nothing, but makes lives miserable for everyone you deal with.

@jaredbusch - I thought that is what you meant but did a double-take. LOL

@ambarishrh Thanks. I just sent him that link to check it out.

@JaredBusch said in Looking for how-to on setting up a proxy: server { client_max_body_size 40M; listen 80; server_name support.bundystl.com; rewrite ^ https://$server_name$request_uri? permanent; } Yep, got all that done and it's working well. What I was referring to was redirecting traffic to HTTPS. Essentially this is the part of the file I was missing... server { client_max_body_size 40M; listen 80; server_name support.bundystl.com; rewrite ^ https://$server_name$request_uri? permanent; }

This way you can share the config(s) under conf.d between multiple machines using the same roles (or whatever Salt calls them) and have different main NGINX server settings.

Yeah me for posting shit always.. Just needed this again. Saw the error and I was like.. hmm I posted about this.

To enable all yum operations to use a proxy server, specify the proxy server details in /etc/yum.conf. The proxy setting must specify the proxy server as a complete URL, including the TCP port number. If your proxy server requires a username and password, specify these by adding proxy_username and proxy_password settings. The settings below enable yum to use the proxy server mycache.mydomain.com, connecting to port 3128, with the username yum-user and the password qwerty. # The proxy server - proxy server:port number proxy=http://mycache.mydomain.com:3128 # The account details for yum connections proxy_username=yum-user proxy_password=qwerty

@gjacobse said: I wonder if Keezel would bypass this? Basically a hardware device doing what Hola does.

@travisdh1 said in Setting up LetsEncrypt on a CentOS 7 NginX proxy: @JaredBusch said in Setting up LetsEncrypt on a CentOS 7 NginX proxy: @aaronstuder said in Setting up LetsEncrypt on a CentOS 7 NginX proxy: Any updates to this? Use Certbot never this method. keep your life simpler. Yeah. If the old way is working, that should keep working. However, certbot is easier to use. When my system came up for renew after certbot was out, I installed certbot and renewed that way. everything is in the same pace. nothing had to be changed in the config files.