- The SWG administrator does not want to use default, self-signed certificate that comes with the appliance on management IP/URL https://mangement-ip:8082
- The SWG administrator wants to use it's own certificate to sign into the Management Console of Proxy signed by it's local Certificate Authority
Release : 7.3.10.0
Issues in following the SSL keyring creation
Tested and verified procedure in lab to replace "default" self-signed SSL keyring with other signed by customer's Certificate Authority:
Sample machines hostnames that are resolved by DNS:
Windows Server CA: dc.yourdomain.local | ProxySG: proxysg.yourdomain.local (192.168.1.156) | Terminal PC is under same Active Directory
01. Select Configuration > SSL > Keyrings. Create a new keyring (Add Keyring) for the ProxySG ex. proxysg.yourdomain.local or test . Select Show Keypair based on your security policy. Click OK and Apply to save your changes.
02. Edit the keyring created above.
03. Click Create under Certificate Signing Request at the bottom.
04. Fill appropriate information into the request. The Common Name can be set to reflect what users should see if viewing certificate details(e.g. Bluecoat SSL interception) Click OK, then Close, then Apply.
NOTE: Common name should reflect the hostname or FQDN of the ProxySG (documentation) ex. proxysg.yourdomain.local
Complete the form, paying close attention to the Common Name field. This should be a hostname or FQDN that resolves to the ProxySG appliance from outside of your protected network. This is the first step in ensuring that Internet-based browsers can trust the certificate the appliance presents.
NOTE: SOME ENVIRONMENTS NEEDS ADDITIONAL ATTRIBUTES FOR THE CSR, WHICH CAN BE ONLY CREATED VIA CLI (versions without SGAC)
If there's no SubjectAltName attribute in the certificate the site will still be shown as insecure with ROOTCA installed. It is advised to create a CSR with SAN over the CLI rather than GUI.
Procedure is almost the same. Keyring can be created from the GUI or CLI:
Proxy> enable
Proxy# config t
Proxy (config)# ssl
Proxy (config-ssl)# create keyring no-show <keyring-name> 2048
Then CSR can be made using this keyring
Proxy (config-ssl)# create signing-request <keyring-name>
Country code []: US
State or province []:
Locality or city []:
Organization name []:
Organization unit []:
Common name []: proxysg.yourdomain.local
Email address []:
Challenge []:
Company name []:
Digest type (sha1, sha224, sha256, sha384 or sha512) [sha256]: sha256
Subject alternative name []: IP:192.168.1.156,DNS:proxysg.yourdomain.local,DNS:proxysg1
Key usage []:
Extended key usage []:
Basic constraints []:
* REQUIRED
(SAN) SubjectAltName attributes > check the formating , worth to add the DNS and IP of Edge SWG(ProxySG)
Then you can see the CSR from the CLI
Proxy (config-ssl)# view signing-request <keyring-name>
Which will be also propagated after a while into the GUI view as well.
05. Edit the created Keyring. At the bottom will now be a certificate signing request (CSR). Copy this text to the clipboard. Click Close.
Ex.
-----BEGIN CERTIFICATE REQUEST-----
[...]
LBlY3B15/Vv3qtjsGSsmn9oWvkrEbL1c/f29LBcB0F6XqpnavUrIlLt79inLHZFx
3QRKTPDs2JLJYfzJaBY7m6oRYVZ1NleFcK1oMyFVGLCVkw4=
-----END CERTIFICATE REQUEST-----
06. Save this text in a file and give it a name such as proxysg.csr. Click Close.
Complete the following steps using Internet Explorer:
07. In Internet Explorer, open the URL of the Mirosoft Certificate Authority server. Generally, the default URL is http://server/certsrv (in our ex. dc.yourdomain.local/certsrv)
08. Click Request a certificate.
09. Click advanced certificate request.
10. Select Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request using a base-64-encoded PKCS #7 file.
11. (Optional) You may be prompted to install "Microsoft Certificate Enrollment Control ActiveX". Click Accept and continue.
12. In the Saved Request field, copy the CSR created above on the Edge SWG(ProxySG). Select Web Server for the Certificate Template. Click Submit.
NOTE: Please do not use the subordinate certification template since it's only used for SSL interception purposes
13. Depending on the configuration of the CA, you may be issued a certificate immediately, or it may need to be approved by an admin. Once approved, select Base 64 encoded and Download certificate.
Save the certificate for the proxy
Ex.
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
14. Click Home in the top right corner of the page to get back to Home of Certificate Authority Server
15. Click Download a CA certificate, certificate chain, or CRL (your domain ROOT_CA)
16. Select the appropriate CA Certificate from the list at the top, select Base 64 as the encoding method and click Download CA certificate.
Complete the following steps on the Edge SWG(ProxySG):
17. In the Management Console on the Edge SWG(ProxySG), select Configuration > SSL > Keyrings. Select the keyring created above and click Edit.
18. Click Import, under Certificate.
19. Paste in the base 64 certificate text generated Web Server certificate from CSR earlier and click Close and then Apply to save your changes.
20. Next, it will be necessary to add the organization Root CA and the Edge SWG(ProxySG) generated certificate from CSR to the list of CA certificates on the Edge SWG(ProxySG). In the Management Console, go to the CA Certificates tab.(Select Configuration > SSL > CA Certificates)
21. Click Import. Name the generated certificate from keyring and paste in the base 64 version of the Edge SWG(ProxySG)'s subordinate CA certificate and click OK and then Apply.
NOTE: You can be notified that CA already exists, then you can skip.
22. Click import. Create name the organization Root CA Certificate and paste in the Base 64 version downloaded above and click OK.
23. Next we will add the Root CA, intermediate CA (if applicable), and proxy certificate as a browser trusted CA. Select CA Certificate Lists tab at the top.
24. Select browser-trusted and click Edit.
25. Select the newly added Root CA, intermediate CA (if applicable), and proxy certificate on the left and click Add to move it to the right column. Click OK and then Apply.
26. Go to Configuration >> Services >> Management Services >> HTTPS-Console and select the new keyring created
27. Certificate should be already used by the Proxy. Open a new browser window or clear the cache in Browser to see the difference.
28. Open the Proxy URL with the hostname used (in this example Internet Explorer was used which has all the root SSL cert from Certificate Authority).
29. Certificate can be additionally verified by downloading it from browser and comparing to the selected SSL keyring
Open a certificate > Details > Copy to File > Save as Base-64 format > Save .cer file on Desktop
Open the downloaded cer file in Notepad++ and compare with the SSL keyring used on Proxy to see if it matches
30. If the Certificate shows untrusted on your PC/browser it means that you need to install the organization Root CA, intermediate cert (optional) or Edge SWG(ProxySG) certificate (optional) on the client PC. Make sure the URL cert is trusted in browser or there will be an issue presented with certification signed by your root Certificate Authority (ex. NET::ERR_CERT_COMMON_NAME_INVALID)
IMPORTANT: Make sure that the certs (rootCA, ProxyCA) are also put in the store “Trusted Root Certification” Authorities on the PC and the browser trusts your CA
https://www.wipo.int/pct-eservices/en/support/cert_import_backup_edge.html
NOTE: Your own CA is not a public, trusted root certification authority like Digicert, Globalsign etc. so it's normal that the site is by default in local envirionment is presented as insecure. The self-signed certificate and root CA is not trusted by the client PC/browser by default unless your terminals are configured trust them forcefully.
Import the certificate to "Trusted Root Certification Authorities" store on the Client PC, so the self-signed cert will be trusted:
https://www.wipo.int/pct-eservices/en/support/cert_import_backup_edge.html
NET::ERR_CERT_COMMON_NAME_INVALID / Certificate "Not Secure" common root causes issues on Client PC:
https://kinsta.com/knowledgebase/net-err_cert_common_name_invalid/