2017年3月28日火曜日

Ruby 2.4.1 release

Install rbenv

$ git clone https://github.com/rbenv/rbenv.git ~/.rbenv
$ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc

$ echo 'eval "$(rbenv init -)"' >> ~/.bashrc
$ git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build

Install ruby
$ rbenv install -l

$ rbenv global 2.4.1

Responding to Symantec's SSL certificate by Google

According to the contents of the following mailing list,
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ

Since January 19, the Google Chrome team has been investigating a series of failures by Symantec Corporation to properly validate certificates. Over the course of this investigation, the explanations provided by Symantec have revealed a continually increasing scope of misissuance with each set of questions from members of the Google Chrome team; an initial set of reportedly 127 certificates has expanded to include at least 30,000 certificates, issued over a period spanning several years. This is also coupled with a series of failures following the previous set of misissued certificates from Symantec, causing us to no longer have confidence in the certificate issuance policies and practices of Symantec over the past several years. To restore confidence and security of our users, we propose the following steps:

  • A reduction in the accepted validity period of newly issued Symantec-issued certificates to nine months or less, in order to minimize any impact to Google Chrome users from any further misissuances that may arise.

  • An incremental distrust, spanning a series of Google Chrome releases, of all currently-trusted Symantec-issued certificates, requiring they be revalidated and replaced.

  • Removal of recognition of the Extended Validation status of Symantec issued certificates, until such a time as the community can be assured in the policies and practices of Symantec, but no sooner than one year.

The SSL certificate of Symantec is the SSL certificate issued by the following organization.

$ wget -O - https://chromium.googlesource.com/chromium/src/+archive/master/net/data/ssl/symantec/roots.tar.gz | tar -x -z -f - -C roots/
$ for cert in roots/*.pem; do openssl x509 -inform pem -in $cert -noout -text | grep Issuer; done | grep -o 'O=[^,]\+' | sort -u

O=Equifax
O=Equifax Secure
O=Equifax Secure Inc.
O=GeoTrust Inc.
O=RSA Data Security
O=Symantec Corporation
O=TC TrustCenter for Security in Data Networks GmbH
O=TC TrustCenter GmbH
O=thawte
O=Thawte
O=Thawte Consulting
O=Thawte Consulting cc
O=The USERTRUST Network
O=VeriSign

2017年3月10日金曜日

Distrusting WoSign and StartCom Certificates

I have a website that uses a StartCom Class 1 Root DV Certificate for encryption & security.
Now, whenever I try to go to my website using the encrypted protocol, I get a privacy error. The exact error is: ERR::CERT_COMMON_NAME_INVALID
When I checked on my StartCom dashboard, it said that all StartCom certificates had been untrusted by Chrome, Mozilla, and Safari.
The reason was written in the following URL.


https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html

https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBGv6szuSB4sMYUcVrR8vQ/preview#


https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/


https://support.apple.com/en-us/HT202858

fd-find

 $ sudo apt install fd-find $ fdfind 石