[openssl-users] free certs: bad idea wosign/startcom/startssl/startencrypt; good alt's

[Johann v. Preußen]

this is a re-worked report i prepared that some might find useful.*

CAUTION:* there are several seriously troubling events surrounding WoSign *^1 * 
(AKA startcom, AKA startssl, and AKA startencrypt) and any of their 
affiliated/subsidiary businesses:

 1. wosign purchased startcom/startssl/startencrypt [DBA's of 'Start Commercial
    LTD' (an Israeli company); hereinafter '*startcom*'] last year. although
    obfuscation by the parties makes determining the actual control-transfer
    date impossible, the change-over may have begun in 2014. both companies long
    completely and publicly denied any change of control even as late as
    2016.JUL despite it being a matter of public record that:
     1.   the entire stock issuance from 15 startcom shareholders including
        founder Revital (AKA 'Eddy') Nigg's majority ownership was transferred
        in 2015.NOV;
     2.   beneficiary of the stock deal was 'StartCom CA Limited' a UK company
        (09744347);
     3.   the UK company is wholly-owned by 'StartCom CA Limited' (yes, exactly
        the same name again) a Hong Kong company (CRN 2271553) with a sole
        director being Wang *^1 *; and
     4.   the Hong Kong entity is then owned by wosign.
 2. in fact, to-date neither firm has actually admitted what has happened re
    transfer of control, domiciling of operations, and changes in management
    personnel. this reticence is despite some aspects of the transactions
    becoming common knowledge in the security community;
 3. wosign attempted (rather poorly it turned out) to make it appear that wosign
    was actually a subsidiary of startcom and startcom's remnant personnel and
    former shareholders abetted this *^2 *;
 4. startcom is an Israeli company and -- as one would expect -- was subjected
    to strict auditing and monitoring by the Israeli government to the benefit
    of all the recipients of their certs ... until the ownership change that is;
 5. wosign is a mainland Chinese (PRC) company which completely controls
    startcom operations in IL, UK, CN, and US;
 6. earlier this year and last wosign -- amongst other deceptive actions -- 
    tried to circumvent certain mandated changes to certificate authority (CA)
    practice by back-/forward-dating certs and issuing certs with duplicate
    serial numbers while their CA compliance auditors Ernst and Young (Hong
    Kong) were complicit in covering up these and other forbidden practices *^3 *;
 7. in response to all these discoveries, mozilla's firefox version 51 and all
    look-alikes using their gecko engine have stopped accepting any new (issued
    on/after 2016.OCT.21) certs that trace back to
    wosign/startcom/startssl/startencrypt root/intermediate/cross-signed certs
    and have banned Hong Kong Ernst and Young CPA's from certifying any CA audits;
 8. unless wosign and its subsidiaries come up with new root certificates and
    provide acceptable audit results for their CP/CPS/operations by 2017.MAR,
    all of wosign-affiliated root/intermediate/cross-signed certs will be
    removed from mozilla's certificate store; and
 9. mozilla has stated that if it detects any further fraud such as exhibited in
    Item 6, /supra/, all security updates to all its software versions will
    immediately remove wosign-based "trusted" certs from the mozilla root
    certificate store on the device being updated which will cause the universe
    of wosign-issued certs to become un-trusted in the mozilla browser family no
    matter when they were issued.

*OBVIOUS CONCLUSION: *do not just walk away from wosign, startcom, qihoo, et 
alii but *RUN! *i can think of nothing worse than trusting a PRC firm with my 
sites' security. OK, if that hyperbole is not enough, try my personal idea of 
what should be network no-go and it pretty much lies in the swath West of Japan 
and East of Germany.

*THE ALTERNATIVE: *the immediate free cert replacement avenue is through 
letsencrypt.org that uses the cert issuance/renewal protocol ACME. although 
letsencrypt will not be found in most (if any) browser "trusted" root 
certificate stores, they use cross-signed intermediate CA certs from a root that 
is. there are an ever-growing number of open-source scripts (bash, perl, python, 
go, ...) available to automate the process which one can even customize for your 
particular needs.

there are letsencrypt plug-ins/modules for apache to make your set-up less 
painful. you can use the nginx process with a lua module to /really /fully 
automate _/everything!/_ if you want to go /de luxe/ there is the openresty 
bundle that combines nginx with lua and adds a host of other nginx "add-in" 
enhancements automatically and some more rarely required that one specifies.

if you have looked at openresty or other bundles before and been turned off 
because there was nothing for your favorite distro/pkg-mgr and the thoughts of 
maintaining a 2kb configure line immediately switched your focus over to happy 
hour, look again! with openresty repo's are in, security patches are quick in 
coming, development is on-going 24/7, the "community" is lively, and the 
original/lead developer still has his hand firmly on the tiller.

one very important plus with the nginx set-up is that tls cert operation under 
lua will actually boot-strap the ACME cert process for each domain and all of 
the permitted sub-domains you authorize in the nginx config file. so, what did i 
just mean?

let us say that you have a new domain 'qwe.com' and want to use the sub-domains 
www, billing, mail, sales, and support. obviously, you have to get the DNS going 
as a separate project (3 minutes). you have to create an on-disk directory tree 
that accommodates the storage of the issued certs and a directory where the lua 
process will operate with the letsencrypt server token process that verifies 
domain control coming through DNS (2 minutes). then, you have a small config 
block in the nginx 'http' section authorizing the sub-directories (2 minutes), 
you drop in a 'server' section for whatever should be done (2 minutes: assuming 
you have an already-established server processing block), and you add to the 
server block a 'location' section for the token process (1 minute). now, you 
re-start nginx *AND YOU ARE DONE (10 minutes total)! *now that you have a 
template, adding on an additional domain should probably run half or less of 
that time.

when the first request comes in for, say, 'www.qwe.com'; nginx calls the lua 
module that completes the whole cert process for getting the cert for that FQDN 
and then services the request ... all without connection interruption. then 
'qwe.com' comes in and it adds that too. then 'support.qwe.com' and so forth 
until all your configured sub-domains are covered. you probably see it now: 
using this simple set-up you can segregate sub-domain access between HTTP and 
HTTPS with that tiny lua sub-domain authorization block. also, by authorizing 
(temporarily or otherwise) nginx to answer for sub-domains for other servers 
such as SMTP[S], IMAP[S], and so forth you will create your own customized 
server certs for apps running any other service you might like on whatever 
sub-domain you please by just making a single request for each server's sub-domain.

cert renewal is also automatic. with no special config, nginx will renew the 
cert when it falls within a remaining window of 30 days.


Thank you,

Johann

_*NOTES:*_

 1. '*WoSign CA Limited*' (hereinafter '*wosign*') has been around in a very
    minor way for, perhaps, as long as a decade. its only known owner is Wang
    Gao Hua (AKA: Richard Wang). it is a demonstrable fact that the PRC
    government is intensely interested in expanding its scope of operation in
    the international security venue and that its multi-faceted security
    apparatus has both overtly and covertly been found to acquire vested
    interests in technology ventures amenable to such an expansion. therefore,
    it is quite imaginable that the PRC government financially facilitated
    Wang's acquisition of startcom for its own purposes. it is all the more
    conceivable given that Wang was not known to be a very wealthy individual or
    well connected with sources of institutional financing.
 2. when i discovered the startling startcom Chinese connection in 2016.JAN and
    asked startcom what was going on, after a long hiatus and several info
    requests i received what was apparently a "canned" response (in re: 'Qihoo"
    since i never made reference to "hosting service" or other network
    security/service offerings such as might come from Qihoo's stable of
    products). moreover, the somewhat fractured English was not up to the
    standard always displayed by startcom in previous correspondence:
    via: 	183.37.145.226 (no rDNS) registered as follows:
    netname: 	CHINANET-GD
    descr: 	CHINANET Guangdong province network
    descr: 	Data Communication Division
    descr: 	China Telecom
    country: 	CN

    /L//ike every big company (IBM, Cisco, Oracle, Microsoft etc.) that has set
    up branch offices and R&D centers in China, StartCom is the No. 6 biggest CA
    in the world and today has also setup branch office and R&D center in
    China///^*1* /, our Chinese R&D team chose Qihoo 360 ^*4*   to provide
    secure hosting service since this company is the No.1 Antivirus and web
    security provider in China and in the world that public listed in
    NYSE///^*5* /.///
    /
    /
    //
    /We are always trying to improve and try support continued growth which
    isn't always easy to sustain. With that we hope to provide you and all our
    customers a useful service.//
    /
    //

    /-- Best regards, Ms. Yael Luft,CVO StartCom Ltd./

    //
 3. Certificate Authority (CA) auditors must certify to several different
    standards (some of which are country-specific) and the most prominent of
    such are:
      * European Telecommunications Standards Institute (*ETSI; *most
        specifically 'TS 102 042'; originally EU-centric and now recognized in
        c. a third of all nations and all of the OECD);
      * Internet Engineering Task Force (*IETF*; most specific policy-wise
        (CP/CPS) 'RFC 3647'; founded by the US and now an independent voluntary
        standards setter);
      * Webtrust Organization (*WEBTRUST*; principally 'WebTrust Principles and
        Criteria for Certification Authorities – SSL Baseline with Network
        Security – Version 2.0'; a network security consortium of commercial
        firms, CPA's, engineers, other standards setters ...);
      * American Institute of Certified Public Accountants (*AICPA*; various
        practice and audit guidelines for businesses, non-profits, and
        governments promulgated through standards boards and US Federal and
        State regulations; an US accountancy professional standards-setting,
        certifier of individuals to practice, and continuing education
        organization);
      * National Institute of Science and Technology (*NIST*; issues various
        publications establishing acceptable modes of operation of public and
        private entities; the lead US agency for standards issuance in
        concordance and co-operation with many other Departments and agencies of
        the US government);

 4. Qihoo 360 is -- like all PRC ISP's, hosting providers, hard-/soft-ware
    vendors, ASN operators, et cetera -- permitted to exist while being
    continuously monitored by the PRC National Defense Council which is a
    second-tier security agency just below the PRC military high command. Not
    only are these permitted firms monitored, but their numbers are severely
    restricted to make that monitoring more easily accomplished. moreover, any
    products of such PRC businesses have to be suspect given their government's
    penchant for intrusive and paramount control of any internal business
    process. of course, the PRC's raids on foreign business and government
    systems should make anyone shrink from any security association with any
    company on mainland china and that includes Hong Kong. Qihoo is addressed
    herein solely because it seems as if there is a Wang business relationship
    and concomitant risk exposure.
 5. pursuant to a privatization agreement back in 2015,  Qihoo 360 Technology
    Co. Ltd. ("Qihoo 360",  a Cayman Islands company) went out of existence and
    its NYSE QIHU ADR's (AKA: ADS's) were permanently suspended from trading on
    2016.JUL.15. although the 2015 announcement mentioned some minority
    financing of the transaction by PRC-controlled subsidiaries of international
    (foreign) banks, the actual finalized financing and even the actual
    ownership of the privatized entity are still totally unknown. since Qihoo
    was originally allowed to thrive within PRC through the PRC military giving
    them a virtual monopoly on many networking services (which they mostly still
    enjoy), it is not a stretch to assume that the military now possesses a
    directly vested interest together with the enhanced control such an interest
    cloaked in secrecy would represent.

On 2016.Oct.25 15:54, Salz, Rich wrote:
>> StartCom has directions on their website. I don't recall what the process is,
>> but I've used it in the past. You might want to review the instructions
>> StartCom provides.
> StartCom, owned by WoSign, has issues with firefox.
>   
>> Let's Encrypt is new and has become very popular. I don't know the process
>> because I have never used them. They will likely suffer more "unable to get
>> local issuer certificate" problems than StartCom, especially on older mobile
>> devices.
> Should not be an issue, since LE has a cross-signed CA cert with someone that is in the trust stores.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161026/3baf8a51/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3825 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161026/3baf8a51/attachment-0001.bin>