I got the email. Here is the full text:

This is an automatically generated email, please do not reply.

Dear customer,

As you are surely aware, the browser makers distrusted StartCom around a year ago and therefore all the end entity certificates newly issued by StartCom are not trusted by default in browsers.

The browsers imposed some conditions in order for the certificates to be re-accepted. While StartCom believes that these conditions have been met, it appears there are still certain difficulties forthcoming. Considering this situation, the owners of StartCom have decided to terminate the company as a Certification Authority as mentioned in Startcom´s website.

StartCom will stop issuing new certificates starting from January 1st, 2018 and will provide only CRL and OCSP services for two more years.

StartCom would like to thank you for your support during this difficult time.

StartCom is contacting some other CAs to provide you with the certificates needed. In case you don´t want us to provide you an alternative, please, contact us at [email protected]

Please let us know if you need any further assistance with the transition process. We deeply apologize for any inconveniences that this may cause.

Best regards,

StartCom Certification Authority

Amusing that they couldn't get the encoding correct on their final email either.

In the email I received, it's a non-ASCII apostrophe encoded in UTF-8. The email headers say "Content-Type: text/html; charset=iso-8859-1", but then the HTML body says "<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>". Clients that give preference to the header will get it wrong.

The full raw email: https://lukeshu.com/dump/startcom-email.txt

eh, the header should match the body encoding regardless of meta tag; should it not?

Yes, the header should match the body encoding, but it doesn't necessarily have to; that is in part what the <meta http-equiv> tag is for; it may be interpreted as saying "the value of header is potentially wrong, use this value instead" (of course, the thing says "http-equiv", and in an email, it isn't an HTTP header, it is a MIME header!)

In HTML4/XHTML1, the <meta http-equiv> isn't meant to be interpreted by the user agent; the HTTP server is supposed to parse it and set the the HTTP header accordingly.

Of course, the people writing the (X)HTML probably have a better idea of what encoding they're using than the people configuring the HTTP server, so it's common for user agents to allow <meta http-equiv> to override the actual header, as it allows more things to work "correctly" for users. But, strictly speaking, that is non-conforming.

In (X)HTML5, that practice was codified, and the <meta http-equiv> tag is given preference over the actual headers (for a whitelist of allowed headers).

So, which interpretation is "correct" depends on if it is HTML4/XHTML1 or (X)HTML5.

Now, the MIME type of the email body said "text/html" which can be anything, and the body used the HTML5 doctype, but specified the XHTML1 xmlns. I'm honestly not sure which interpretation is correct in that case.

ISO-8859-1, aka "Latin 1" is a single-byte encoding but it represents the Unicode codepoints 0-127 (ASCII) in exactly the same way as UTF-8. This is a legacy of Microsoft Windows.

This is more common than you think.

It’s correct in the email I received. It’s a non-ascii apostrophe so I guess certain mail clients might not handle it correctly?

I copied and pasted from Outlook... probably Outlook's fault honestly.

Probably just a roundabout way to say that they're selling their customer data and you have to contact them to opt out.

Thank you very much for pointing out about the opt-out crap. I also got the email but I didn’t bother to read past the first paragraph because I stopped using them as soon as I switched to cloudlfare for my certificates.

I always hated their interface but as a broke high school student I couldn’t afford to have a paid certificate. Thankfully we have Let’s Encrypt now

I have received a follow up email by them in a very timely manner:

    > Hi,
    > 
    > Sure, we will record your user ID and your details won't be transferred to other CA, as the alternative CA option is for those who need it.
    > 
    > Best regards,
    > StartCom Certification
    > Authority

Text of the email is here: https://pastebin.com/6BCCFtJx

I received the email, and I agree, I thought "Just leave me and my certificates alone would you?" They did enough damage already

Maybe you get a shiny new Turk Trust cert in exchange. Who knows.

I have no idea if 'Turk Trust' is even a real CA or if you made up the name in jest. I'm honestly scared to Google it and find out, in slight fear of finding out that is an actual CA. (Not to get too political here, but given Turkey's current government, I'm not sure how anyone in their right mind would 1- trust them to say or do _anything_, and 2- trust SSL encryption certs coming out of there)

At least it's not Honest Achmed's Used Cars and Certificates ;)

https://bugzilla.mozilla.org/show_bug.cgi?id=647959

Interestingly:

> Eddy Nigg (StartCom)

> Comment 11 • 7 years ago

> According to http://www.mozilla.org/projects/security/certs/policy/ and https://wiki.mozilla.org/CA:Information_checklist apparently fails to comply to the audit requirements amongst other things at the moment. Should a valid audit statement be published and confirmed by an authorized auditor, I guess Mozilla could consider a discussion to include this CA.

LMAO

I'm Turkish and I agree. Also, Turk trust got involved in a controversy where they admitted that they leaked a private key. https://www.google.com.tr/amp/s/nakedsecurity.sophos.com/201...

It's real:

https://bugzilla.mozilla.org/show_bug.cgi?id=1007683

Why Turk Trust?

... basically the top google search result

https://nakedsecurity.sophos.com/2013/01/08/the-turktrust-ss...