Home » Posts tagged "certificate" (Page 2)

TWCA 不在 Java Trust Store 裡...

SSL Labs 上翻資料的時候發現看到台灣有些網站的 SSL 憑證在 Java Trust Store 內是不會取得信任授權的,但其他的都支援,像是這樣:

翻了幾個後發現都是 TWCA 的,在其他家都是這樣授權出來的 (Mozilla/Apple/Android/Windows):(TWCA Root Certification Authority -> ) TWCA Global Root CA -> TWCA Secure SSL Certification Authority -> Final,也就是 TWCA 的兩個 Root CA 都在 trust store 內,走任何一條授權都可以拉出來。

印象中之前應該都是支援的... 先前是 cross sign 嗎?@_@

AWS Certificate Manager 提供 Private CA

AWS Certificate Manager 推出了 Private CA,讓使用者可以在不接觸到 CA 的 Private Key 就可以操作 CA 行為:「AWS Certificate Manager Launches Private Certificate Authority」。

支援的演算法除了標準的 RSA 外,還包括了 ECC 的 (雖然是 NIST 的 P-256 與 P-384):

然後直接內建了 CRL 服務,透過 Amazon S3 做:

要注意的是價錢有點奇怪:

Private CAs cost $400 per month (prorated) for each private CA. You are not charged for certificates created and maintained in ACM but you are charged for certificates where you have access to the private key (exported or created outside of ACM). The pricing per certificate is tiered starting at $0.75 per certificate for the first 1000 certificates and going down to $0.001 per certificate after 10,000 certificates.

中間省掉 1k 到 10k 是 USD$0.35/cert (可以在 pricing 頁面看到)。

不管如何,這計價模式有點怪怪的... 收了固定的費用,每個 certificate 的費用要到 USD$0.75,這看不太懂。另外是 10k 後的單價明顯與前面比例不太合。

看起來像是跟某個 partner 合作談出來奇怪的 pricing model,但也不知道是哪家... :o

Facebook 的 Certificate Transparency Monitoring 工具

前幾天找資料才發現原來 Facebook 很早就有提供 Certificate Transparency 相關的服務,可以用網域名稱搜尋查詢,甚至是訂閱:「Introducing our Certificate Transparency Monitoring tool」。

服務在「Certificate Transparency Monitoring - Facebook for Developers」這邊,搜尋與訂閱都可以在這邊處理。

tp.edu.twntpc.edu.tw 可以看到不少學校都用 Let's Encrypt 的服務,像是「臺北市內湖區碧湖國小全球資訊網」這個 (雖然一進去就看到 flash...)。

Cloudflare 的 CT Dashboard

Cloudflare 發表了他們的 CT (Certificate Transparency) Dashboard:「Introducing Certificate Transparency and Nimbus」。前面的篇幅解釋 CT 是什麼,以及為什麼要存在,另外也大略解釋了一下 Google 要求要帶有 SCT (signed certificate timestamp) 的新規定 (基於 Browser 方,也就是 Google Chrome 的立場)。

再來就是講 Cloudflare 推出的 Dashboard,也就是 Merkle Town。這個網站提供了網頁操作界面,讓大家可以了解現在 certificate 的情況。

點了 Current 後,可以看到 Let's Encrypt 的比率相當高,但 Comodo 的量不算差 (以收費的情況來說),再來是 DigiCert

話說回來,當所有的 SSL certificate 都需要 SCT 後,相當於一般人就能夠很精確的統計市占率了,商業的憑證公司應該不是很開心... (當初 EV 也有類似的問題,不過現在 DV 已經被 Let's Encrypt 打趴了...)

Let's Encrypt 的 Wildcard Certificate 開放使用!

Twitter 上看到這則 tweet,Let's Encrypt 正式開放 Wildcard Certificate 了:

參考「ACME v2 and Wildcard Certificate Support is Live」這邊的說明,裡面有提到 Wildcard Certificate 需要有 ACMEv2 的 client:

Wildcard certificates are only available via ACMEv2. In order to use ACMEv2 for wildcard or non-wildcard certificates you’ll need a client that has been updated to support ACMEv2. It is our intent to transition all clients and subscribers to ACMEv2, though we have not set an end-of-life date for our ACMEv1 API yet.

翻了一下「ACME Client Implementations」,我常用的 dehydrated 也支援 ACMEv2 了,而且剛好前幾天我更新了 PPA (參考「PPA for dehydrated : Gea-Suan Lin」),把最新版 (0.5.0 後的 6e802dd) 包進去了,等下來測試看看要怎麼玩 XDDD

然後我之後打算把 letsencrypt.tw 的資料改丟到我的 Wiki 上,這樣改起來比較簡單...

今年十月 Firefox 將完全不信任 Symantec 簽出的 SSL Certificate

Mozilla 旗下的產品 (包括 Firefox) 將在今年十月對 Symantec 簽出的 SSL Certificate 終止信任:「Distrust of Symantec TLS Certificates」。

Mozilla 有把發生的事情都整理出來:「CA:Symantec Issues」,另外 Firefox 的動作分成三個階段,目前 stable 是 58,但 nightly 是 60 了:

  • January 2018 (Firefox 58): Notices in the Browser Console warn about Symantec certificates issued before 2016-06-01, to encourage site owners to replace their TLS certificates.
  • May 2018 (Firefox 60): Websites will show an untrusted connection error if they use a TLS certificate issued before 2016-06-01 that chains up to a Symantec root certificate.
  • October 2018 (Firefox 63): Distrust of Symantec root certificates for website server TLS authentication.

去年 Google Chrome 就有先丟出對 Symantec CA 的計畫 (參考「Google Chrome 對 Symantec 全系列憑證的不信任計畫」這篇),看起來 Mozilla 的計畫也差不多,但時間有些差異...

Let's Encrypt 的 Wildcard Certificate 將會再延...

先前有提到 Let's Encrypt 的 Wildcard Certificate 從一月延到二月底 (表訂 2/27,參考先前的「Let's Encrypt 的 Wildcard SSL Certificate 延至二月底推出」這篇),今天想說歐美的時區也差不多要過完 2/27 了,結果翻資料發現在「ACMEv2 and Wildcard Launch Delay」這邊又宣佈延期了,這次也不給時間了 XDDD

主要是 TLS-SNI 認證方式的前提有問題,導致 Let's Encrypt 臨時調度人力處理這個包 (可以參考「2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure」這篇,裡面有提到共用產生的問題假設):

The biggest reason for this delay is the recent TLS-SNI deprecation. This unexpectedly pulled most engineering resources away from ACMEv2 and wildcard support for approximately two weeks.

然後 2/27 的說明提到目前是沒什麼大問題,但目前還在 QA 階段,然後目前先不給 release date:

Feb 27 Update: There are no known major issues with the ACMEv2/wildcard test endpoint. ACMEv2 and wildcard support quality assurance is continuing. No release date to announce yet.

就只能繼續等了... XD

SSL Certificate 的認證方式限縮

在「Ballot 218 - Remove validation methods 1 and 5 - CAB Forum」看到「Ballot 218: Remove validation methods #1 and #5」這則議案以 78% 的同意票通過,限縮 SSL Certificate 的認證方式。眼睛瞄到中華電信投下反對票:

14 Yes votes: CFCA, Cisco, Comodo CA, D-TRUST, DigiCert, GDCA, GlobalSign, GoDaddy, Izenpe, Let’s Encrypt, Logius PKIoverheid, SSL.com, TrustCor, Trustwave

4 No votes: Buypass, Chunghwa Telecom, Entrust Datacard, SwissSign

4 Abstain: Actalis, Disig, HARICA, OATI

78% of voting CAs voted in favor

找了一下在 BR (Baseline Requirements) 的 3.2.2.4.1 與 3.2.2.4.5,其中前者是透過註冊商認證:

3.2.2.4.1 Validating the Applicant as a Domain Contact

Confirming the Applicant's control over the FQDN by validating the Applicant is the Domain Contact directly with the Domain Name Registrar.

後者是透過文件認證:

3.2.2.4.5 Domain Authorization Document

Confirming the Applicant's control over the FQDN by relying upon the attestation to the authority of the Applicant to request a Certificate contained in a Domain Authorization Document.

在想投下反對的原因,會不會是因為中華自己的 domain 應該都是透過後者方式發的?透過內部公文系統...

Let's Encrypt 的 Wildcard SSL Certificate 延至二月底推出

Let's Encrypt 本來預定在一月底時推出 Wildcard SSL Certificate (參考「Let's Encrypt 決定要規劃 Wildcard SSL Certificate 了」),昨天突然想到應該是要推出了... 查了資料發現在原本的公告文章上宣佈延到二月底了:「Wildcard Certificates Coming January 2018」。

Update, January 4, 2018

We introduced a public test API endpoint for the ACME v2 protocol and wildcard support on January 4, 2018. ACME v2 and wildcard support will be fully available on February 27, 2018.

所以再等一個月吧...

Amazon CloudWatch Logs 換 SSL Certificate 的 CA

收到標題是「Upcoming Changes to SSL Certificates in Amazon CloudWatch Logs」的信件,說明 Amazon CloudWatch Logs 要換 SSL Certificate 的 CA,看起來是要換成自家的:

We will be updating the certificate authority (CA) for the certificates used by Amazon CloudWatch Logs domain(s), between 8 January 2018 and 22 January 2018. After the updates complete, the SSL/TLS certificates used by Amazon CloudWatch Logs will be issued by Amazon Trust Services (ATS), the same certificate authority (CA) used by AWS Certificate Manager.

然後有提到 cross-sign 的部份,有透過 Starfield 的 Root CA 簽,所以只要下面有任何一個有在 Root CA store 裡面就應該會信任:

The update means that customers accessing AWS webpages via HTTPS (for example, the Amazon CloudWatch Console, customer portal, or homepage) or accessing Amazon CloudWatch Logs API endpoints, whether through browsers or programmatically, will need to update the trusted CA list on their client machines if they do not already support any of the following CAs:
- "Amazon Root CA 1"
- "Starfield Services Root Certificate Authority - G2"
- "Starfield Class 2 Certification Authority"

另外條列出有哪些 API endpoint 會改變:

This upgrade notice covers the following endpoints:
logs.ap-northeast-1.amazonaws.com
logs.ap-northeast-2.amazonaws.com
logs.ap-south-1.amazonaws.com
logs.ap-southeast-1.amazonaws.com
logs.ap-southeast-2.amazonaws.com
logs.ca-central-1.amazonaws.com
logs.eu-central-1.amazonaws.com
logs.eu-west-1.amazonaws.com
logs.eu-west-2.amazonaws.com
logs.eu-west-3.amazonaws.com
logs.us-east-1.amazonaws.com
logs.us-east-2.amazonaws.com
logs.us-west-1.amazonaws.com
logs.us-west-2.amazonaws.com
logs.sa-east-1.amazonaws.com

然後也列出了有哪些系統「應該」會支援:

* Operating Systems With ATS Support
- Microsoft Windows versions that have January 2005 or later updates installed, Windows Vista, Windows 7, Windows Server 2008, and newer versions
- Mac OS X 10.4 with Java for Mac OS X 10.4 Release 5, Mac OS X 10.5 and newer versions
- Red Hat Enterprise Linux 5 (March 2007), Linux 6, and Linux 7 and CentOS 5, CentOS 6, and CentOS 7
- Ubuntu 8.10
- Debian 5.0
- Amazon Linux (all versions)
- Java 1.4.2_12, Java 5 update 2, and all newer versions, including Java 6, Java 7, and Java 8

不過沒看到 Windows XP 耶,不知道是怎樣 XD

Archives