Create Certificate chain and sign certificates using Openssl

  1. Generate Root Certificate key.
    openssl genrsa –out RootCA.key 4096
    1-Create RootCA Key

  2. Generate Root certificate.
    openssl req –new –x509 –days 1826 –key RootCA.key –out RootCA.crt
    2-Create RootCA Certificate

  3. Generate Intermediate CA certificate key
    openssl genrsa –out IntermediateCA.key 4096
    3-Create IntermediateCA Key

  4. Generate Intermediate CA CSR.
    openssl req –new –key IntermediateCA.key –out IntermediateCA.csr
    4- Create IntermediateCA CSR

  5. Sign the Intermediate CA by the Root CA.
    openssl x509 –req –days 1000 –in IntermediateCA.csr –CA RootCA.crt –CAkey
    key – CAcreateserial –out IntermediateCA.crt
    6- Sign the IntermediateCA CSR using RootCA

  6. Generate Server certificate key
    openssl genrsa –out Server.key 2048
    8-ServerCert Key

  7. Generate Server certificate CSR.
    openssl req –new –key Server.key –out Server.csr
    9- Create Server Cert CSR
  8. Sign the Server Certificate CSR using the Intermediate CA.
    openssl x509 –req –days 1000 –in Server.csr –CA IntermediateCA.crt –CAkey
    key – set_serial 0101  –out Server.crt –sha1
    10- Sign the Server cert CSR using IntermediateCA

NOTE:
A. This is an add-on for Linux system, especially in cases where you will have to import the certificates in the cert store of Linux systems.

Copy the certificate in the trusted store in Linux:
   Root# cp *.crt  /usr/local/share/ca-certificates/
Root# update-ca-certificates
7- Copy Root and IntermediateCA to the certificate store

B.
To view the key or the certs or the csr generated as per the steps mentioned above use the command “ls”.
Root# ls -l
5- Verify keys certs csr created so far

C. Verify the certificate.
      openssl x509 –in Server.crt –noout –text | grep ‘host.local’

After the Global Protect is disconnected, wireless adapters are unable to restore the DNS configuration.

Here is an issue that has been observed with Palo Alto Network’s Global Protect VPN.
A] Problem Description :
      ==================
— Users use wireless network for successful global protect connection.
— After the GP is disconnected, wireless adapters are unable to restore the DNS configuration.
— I have tested the working with GP Agents 2.3.4, 3.1.0 , 3.1.1, 3.1.2, 3.1.3 and 3.1.4. All of these versions show same behavior.
— References Release Notes:
Issue Identifiers : Release Note
102244 : 3.1.1
100000 : 3.1.2
GPC-3363 : 3.1.3
GPC-3431 : 3.1.4

B] Expected behavior should be : After GP is disconnected, the DNS configurations pushed from the FW should be flushed.

C] This is a known bug, however here is a work around that I came up with.

  1.  Configure a batch script to set the dns of the wireless adapters to dhcp.(Filename: SetDNSScript.bat).
    setdnsscript
  2. Customize the Global Protect msi installer to run the script after GP disconnects.
    You can do this using msiexec – a windows Installer program. Open the command prompt and type the following :
    ” msiexec /i GlobalProtect64.msi PREVPNDISCONNECTCOMMAND=”C:\SetDNSScript.bat” PREVPNDISCONNECTCONTEXT=”admin” PREVPNDISCONNECTFILE=”%userprofile%\SetDNSScript.bat” PREVPNDISCONNECTERRORMSG=”Failed executing post-vpn-connect action” “
  3. You may create a create a batch file to perform deployment(Filename: DeployGP.bat).
  4. This resolved the issue.

    NOTE :
    a) The problem here is we need admin rights or the admin credentials to set the dns of the wireless adapters to dhcp. Practically this wont be possible if the issue is being face by large number of users (users with out admin rights).

    b) DeployGP.bat :
    —————-
    msiexec /i GlobalProtect64.msi PREVPNDISCONNECTCOMMAND=”C:\SetDNSScript.bat” PREVPNDISCONNECTCONTEXT=”admin” PREVPNDISCONNECTFILE=”%userprofile%\SetDNSScript.bat” PREVPNDISCONNECTERRORMSG=”Failed executing post-vpn-connect action”

    SetDNSScript.bat :
    —————
    psexec -u <admin_name> -p <admin_password> netsh interface ip set dns “<Name of Adapter 1>” dhcp
    psexec -u <admin_name> -p <admin_password> netsh interface ip set dns “<Name of Adapter 2>” dhcp
    psexec -u <admin_name> -p <admin_password> netsh interface ip set dns “<Name of Adapter 3>” dhcp
    psexec -u <admin_name> -p <admin_password> netsh interface ip set dns “<Name of Adapter 4>” dhcp
    psexec -u <admin_name> -p <admin_password> netsh interface ip set dns “<Name of Adapter 5>” dhcp
    ipconfig /renew
    pause

Palo Alto Firewalls – Unable to decrypt SSL Inbound traffic.

Scenario : Hosts from internet connects to the web server behind the Palo Alto firewall. Traffic log shows that traffic is not being decrypted.

1. There can be multiple reason why the inbound traffic is not being decrypted. One of the most common reasons is unsupported cipher suites. But this article is about Extended Master Secret and SSL Inbound Decryption.

2. Global counters reflects the following :
=================================
proxy_process 6 0 info proxy pktproc Number of flows go through proxy
proxy_wqe_queued 5 0 info proxy resource The number of wqe currently held as part of proxy
proxy_reverse_failure 1 0 warn proxy pktproc The number of sessions failed for reverse proxy
proxy_decrypt_error_overall 1 0 info proxy pktproc Overrall number of decrypt error(not including cert validation and unsupport param)
ssl_hs_mac_error 1 0 warn ssl pktproc ssl handshake mac state unmatched with version
ssl_client_sess_ticket 6 0 info ssl pktproc Number of ssl session with non empty client sess ticket ext

3. Analyze ssl basic, you will came across handler error -20.

4. Go for a packet capture on the firewall. You should find extended master secret being used by both client and the server.

Sample snap shot:

11

5.  Extended Master Secret Extension (RFC7627) has been activated by Microsoft with Security Update for Schannel to Address Spoofing (3081320). This affects software using Schannel including IIS and IE. Latest version of Google Chrome also has the extension activated. OpenSSL will support it with 1.1.0.

6. When the extension is present in both Client Hello and Server Hello, master secret computation differs from that described in RFC 5246, and therefore we cannot decrypt sessions using it with inbound SSL decryption. Palo Alto Firewall does not support decryption in such scenarios.

7. Workaround is to disable Extended Master Secret in SChannel on both the IIS and the Client.
To make these registry changes, follow these steps:

1.  Click Start, click Run, type regedit in the Open box, and then click OK.

1
2.  Locate and then click the following subkey in the registry:
3.  HKLM\System\CurrentControlSet\Control\SecurityProviders\Schannel

2a

Scroll Down :

 

3a
4.  On the Edit menu, point to New, and then click DWORD Value.
5.  For the computer that is receiving the connection request, type     DisableServerExtendedMasterSecret ( DisableClientExtendedMasterSecret for Client):   REG_DWORD for the name of the DWORD, and then press ENTER.

4
6.  For the computer that is initiating the connection request, type DisableClientExtendedMasterSecret ( DisableClientExtendedMasterSecret for Client) for the name of the DWORD, and then press ENTER.
7.  Right-click the new DWORD entry, and then click Modify.
8.  Type 1 (or any non-zero value) in the Value data box to disable the TLS extension.

5

 

6

NOTE : After making these changes you will find that the traffic is being decrypted. But practically, it is not possible to disable Extended Master Secret in SChannel for clients as most of the times we do not have control over the clients/traffic coming in from the internet.

 

Easy way to check SSL negotiation details

1. An easy way to check SSL negotiation details between a client and a server is to use openssl.

2. In a Linux system (ex: Kali Linux), use openssl s_client to verify the negotiation details.

3. Open a shell in linux

KL1.JPG

4. Commands used

a. #openssl

b. #s_client -connect www.systemstudio.com:443  –> NOTE : <domain name>:<443>

KL2.JPG

5. Sample output :

OpenSSL> s_client -connect www.systemstudio.com:443
CONNECTED(00000003)
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign Domain Validation CA – SHA256 – G2
verify return:1
depth=0 OU = Domain Control Validated, CN = cc.sedoparking.com
verify return:1

Certificate chain
0 s:/OU=Domain Control Validated/CN=cc.sedoparking.com
i:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Domain Validation CA – SHA256 – G2
1 s:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Domain Validation CA – SHA256 – G2
i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA

Server certificate
—–BEGIN CERTIFICATE—–
MIIE8jCCA9qgAwIBAgISESGTb+pqujeMpyMkW48SWnhQMA0GCSqGSIb3DQEBCwUA
MGAxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTYwNAYD
VQQDEy1HbG9iYWxTaWduIERvbWFpbiBWYWxpZGF0aW9uIENBIC0gU0hBMjU2IC0g
RzIwHhcNMTUxMTExMDg0NTQwWhcNMTcxMTExMDg0NTQwWjBAMSEwHwYDVQQLExhE
b21haW4gQ29udHJvbCBWYWxpZGF0ZWQxGzAZBgNVBAMTEmNjLnNlZG9wYXJraW5n
LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALSX9ixYi6cB09+r
yhtRS1lh0wd11WhccAWnPq0kXp7+PnkUkv+wjRFZ/bjk/l+LPO8HwPWLYhKlembV
54Fn+UJyvEpvBuEF7iX7+PW89Aymmx4/2Fggln4ozO3qFHpNBo/IJVet5YTMIqm7
PGNzR6V7NT8e8wGDqeFHKoEdxxIFNpXPNxCOPF2ZbFffATeIBqY+0QGB+NWM/emu
BYGkzkmoZRnHFH7+9INwCvPIo78xTInZQQMX1OvxX1AhEzw2U0JH9nVHLguQKuwr
u1uUMMQScx4o/0g2flmpMMa7Eep4Z+HJnuGE4NnBBzcg4M06kxByFWD1xULkYysO
b5907YMCAwEAAaOCAcQwggHAMA4GA1UdDwEB/wQEAwIFoDBJBgNVHSAEQjBAMD4G
BmeBDAECATA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNv
bS9yZXBvc2l0b3J5LzAdBgNVHREEFjAUghJjYy5zZWRvcGFya2luZy5jb20wCQYD
VR0TBAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwQwYDVR0fBDww
OjA4oDagNIYyaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9nc2RvbWFpbnZh
bHNoYTJnMi5jcmwwgZQGCCsGAQUFBwEBBIGHMIGEMEcGCCsGAQUFBzAChjtodHRw
Oi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2RvbWFpbnZhbHNoYTJn
MnIxLmNydDA5BggrBgEFBQcwAYYtaHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29t
L2dzZG9tYWludmFsc2hhMmcyMB0GA1UdDgQWBBQOb+sP/EvKLwTF/twbuKVfMeHD
ajAfBgNVHSMEGDAWgBTqTnzUgC3lFYGGJoyCbcCYpM+XDzANBgkqhkiG9w0BAQsF
AAOCAQEAUctF7dn2Zc9Lgv2k/AIwLgDYdHLFJD0yOhHFKuuR4vYmGS3mQ0y42FDT
SP7wiZRqEb+UUt/BaXYwo/rcRZUEtuuEDIfz4vbvUpJMBCLDG3Ft6YtK0+DApVp0
5MPhtB1LhPZhEH3BZUwmGlgtjH7ZVTNgr25DrFElkBD9bmdxH6xSLCrGzs3zzuz+
0+a2UigS+rcLHGnQA/9B+8quor/0HUUv2D68AbX7M9j9CKwYGYhYDlmvEyGLZz37
eceoZOGY8Voq9a/8HrOHcmxndjRQzx2takCQiYCUKazoeoQcbaP8uLefnNlcbJp7
psu5hAM6+KZceZ8GXoON9uO0Cj3tQA==
—–END CERTIFICATE—–
subject=/OU=Domain Control Validated/CN=cc.sedoparking.com
issuer=/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Domain Validation CA – SHA256 – G2

No client certificate CA names sent

SSL handshake has read 2716 bytes and written 641 bytes

New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID: ACE8E9B4C38D3B63359EEB4016C2FA3424AEC582ABCE4E293C92E4E717CD7D26
Session-ID-ctx:
Master-Key: 3B26FC8251A071FEB876387781B1D49DAF22EB2612B2C61BCB6DCE346CDE59B71EF8D0DCF072BFAE4B1AD331CA579C9A
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket:
0000 – e0 16 d4 ce bb fb b5 cb-32 ef 2c b2 0d a0 a9 76 ……..2.,….v
0010 – 2b 59 82 09 1f 78 a3 67-ca 14 23 00 66 22 d6 8d +Y…x.g..#.f”..
0020 – 01 2d d7 eb 76 4b 99 47-ad 29 10 52 7f 2f a3 e1 .-..vK.G.).R./..
0030 – a3 46 80 a4 dc 2f df b7-c6 a0 07 43 53 7d 4e d7 .F…/…..CS}N.
0040 – 61 c1 a8 0a c5 f4 eb 6d-3c eb 8e 76 24 94 04 99 a……m<..v$…
0050 – e8 3d eb cb f1 ba b1 0f-ff 24 59 2f cf d5 f0 50 .=…….$Y/…P
0060 – 83 4d 28 54 b8 c5 38 b6-bc d6 f6 8f 9d 45 9c 59 .M(T..8……E.Y
0070 – 62 36 75 4c e4 a8 8b 30-79 1f 24 be 36 93 57 24 b6uL…0y.$.6.W$
0080 – 44 84 dc c0 04 3c b0 0d-9c 09 2b 61 14 c4 bf 06 D….<….+a….
0090 – 4d 60 79 90 11 49 cf 86-f0 bc 74 16 de f3 fe e3 M`y..I….t…..

Start Time: 1462909951
Timeout : 300 (sec)
Verify return code: 0 (ok)