Masalah
Mencari masalah
➜ ~ openssl s_client -showcerts -connect w.r.com:8243 -prexit
CONNECTED(00000003)
depth=0 CN = *.r.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = *.r.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:CN = *.r.com
i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = GeoTrust RSA CA 2018
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
---
Server certificate
subject=CN = *.r.com
issuer=C = US, O = DigiCert Inc, OU = www.digicert.com, CN = GeoTrust RSA CA 2018
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2073 bytes and written 442 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID:
Session-ID-ctx:
Master-Key:
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1605686760
Timeout : 7200 (sec)
Verify return code: 21 (unable to verify the first certificate)
Extended master secret: yes
---Masalah dan Solusi
Masalahnya terjadi karena miskonfigurasi di server. Sertifikat yang di berikkan ke server hanya sertifiakt, private key. Tidak ada chain/intermediate ca yang diberikan ke server. Solusinya adalah menambahkan chain/intermediat ca ke server. Atau jika server hanya menyediakan certificate dan private key, isi certificate dengan certificate + chain (istilahnya fullchain jika menggunakan lets encrypt)
Mengapa di browser jalan
Browser ditanami oleh ROOT CA certificate, dan beberapa CHAIN CA. Sedangkan aplikasi/postman/terminal curlhanya ditanami ROOT CA. Sehingga di browser tidak error
Apa itu Root/Chain/Intermediate
Hanya ada beberapa (dikit) pihak yang menerbitkan sertifikat. Menurut wikipedia ada 147 https://en.wikipedia.org/wiki/Certificate_authority. Salah satu contohnya adalah VeriSign. Ketika orang ingin membeli sertifikat apakah langsung beli ke VeriSign ? jawabannya adalah tidak. Karena akan sangat ribet jika hanya dihandle oleh 147 root authorities. Jadi ketika Root CA( VeriSign) member akses ke Chain CA(Symantec) untuk menerbitkan sertifikat, kita hanya perlu minta ke Chain CA (Symantec) . Chain CA (Symantec) bisa menerbitkan sertifkat berapa pun jumlahnya tanpa seizin Root CA(Versigin) karena sudah diberi Kunci oleh Root CA.
Out of topic dikit, Ini mirip mirip seperti Nameserver atau DNS atau nama domain, tidak tersentralisasi untuk lebih mudah mengatur dan skalabilitasnya. Ketika anda membuka blog ini (abdillah.my.id) DNS anda (misal google 8.8.8.8, asumsikan tanpa cache/TTL) akan mengecek alamat dari nameserver/DNS Server (NS) top level domain id, dan meminta alamat name server dari my.id. Misal NS my.id adalah 2.2.2.2, lalu si DNS google akan mengakses NS my.id (2.2.2.2) untuk mencari NS abdillah.my.id (3.3.3.3). Akhirnya, DNS google akan mengakses NS abdillah.my.id(3.3.3.3) untuk mencari record A/CNAME atau IP dari root domain abdillah.my.id (100.100.100.100). Misal saya punya 3 subdomain (app1.abdillah.my.id, app2.abdillah.myid, abdillah3.abdillah.my.id) berarti kita punya 3 record A/CNAME di dns. 3 record tidak disimpan di NS .id ataupun my.id, namun hanya di simpan di NS abdillah.my.id (3.3.3.3). Istilah dari teknik ini adalah Reverese Nameserver Lookup
Oke balik lagi ke SSL, selain desentralisasi/kemudahan adalah karena kemanan. Jika private key dari Chain CA bocor, maka tidak ada masalah bagi ROOT Ca ataupun chain CA yang lain. Hanya chain CA yang bermasalah yang perlu di revoke certificate nya dan di update.