Tell HN: Digicert is turning into Symantec
Then they "absorbed" Symantec.
First, the quality of the support took a nose dive. Live chat that used to be almost instantaneously available started showing queues of 10-15 minutes. Earlier this year the support started deflecting all sales-related questions to "your sales representative, who will get in touch with you shortly." What useв to be a 30 second chat to get the renewal price matched against the last year now turned into some painful bullshit that ended up with sales rep claiming no discounts were available, but he'd be willing to make a massive one-time exception of 5% off.
But the /sysdev link still worked, the hope that these Symantec influences will blow over was still there.
No more. The link now redirects to $600/yr pricing. Support is slow and useless, there are now industry-standard obnoxious sales reps, where none is needed, and so Digicert is all but Symantec now. What a shame I say.
Just FYI.
[1] https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/get-a-code-signing-certificate
43 comments
[ 2.9 ms ] story [ 106 ms ] threadI can't really imagine someone who needs to use a text merge tool, and uses a Linux desktop, but finds it overwhelming to run, at most, 3 commands.
Just in case it's not clear: there are none. You just download the file and run it. That's the problem that Microsoft code signing certs solve. Sure, it's not overwhelming, but without thinking about UX 2020 won't be the year of Linux Desktop. "5 different package managers" is part of the problem.
The text merge tool is just an example.
I guess you learn something every day.
Additional:
> "5 different package managers" is part of the problem.
Problem for who?
Code signing allows software vendors to opt in to a reputation based scheme of authenticating software. There is nothing like that on Linux. There are similar systems within distros (Debian Developers, Arch TU etc.) but each one of them is for that one particular distro.
EV Code Signing certs require that the private key is stored on a hardware token (so it's harder to misuse). This is also something that's not utilized by packagers.
Code signing doesn't solve world hunger but it doesn't mean it's all evil.
> Problem for who?
ISVs and ultimately their users.
It is a solution to a massive problem with average, technically unsophisticated users downloading and running all sort of junk without thinking twice, including things that impersonate legit software and generally do shady stuff like dropping random kernel modules.
The business scaffolding around it is just wrong, I agree with that. It should be handled by non-profits or state-run organizations. You register a company, you get a signing key. Validation and authentication should be done at source, not across an ocean by a 3rd party outsourced support calling a phone number published in 4th party business directory. This is as ass-backwards as it gets.
It's a scam. Full stop.
A standard cert is now free. $0. Nada. Zilch.
So what are the power-players doing? They're deprecating the validity of 'those free certs', and pushing EV.
What does EV do? Oh yeah "You paid $X hundred so you MUST be legit". Sure, they might look at the state's business registry and match the business name in the EV. That's automatable work.
But there you have it, piles of money because 'a real business can afford it'. And some assumption that scammers wont.
Cert chains from the root authorities have been a continual scam, until LetsEncrypt showed up. This EV bullshit is no different.
Imagine you said the same thing about web certificates prior to Let's Encrypt, does that mean Let's Encrypt is just a scam? No, web certs have inherent technical value everyone was just getting raked over the coals on pricing. Same thing here, there is no "full stop" as signing certs have value but the companies are charging far more than is reasonable.
> [...]
>Cert chains from the root authorities have been a continual scam, until LetsEncrypt showed up. This EV bullshit is no different.
You seem to be conflating web certificates (for lack of a better term) with code signing certificates. When it comes web certificates, 3 of the 4 major browser vendors are removing EV indications from their UI[1], so I'm not sure where this "push" is from. On the other hand, for code signing certificates, there is a push from MSFT to get EV certificates, since it automatically gains "smartscreen reputation".
[1] https://www.troyhunt.com/extended-validation-certificates-ar...
>But there you have it, piles of money because 'a real business can afford it'. And some assumption that scammers wont.
Like it or not, when it comes to everyday windows users, code signing has the best ux compared to other forms of validation. Right-click -> properties and it shows who signed it and whether it was tampered with. This is much better than posting a file hash (how do you calculate a hash? what happens if the landing page is compromised?), or GPG (how do you install GPG? how do you build up web of trust? are you going just use whatever key that the download page says to use?)
Two suggested better terms for future reference:
Certificates in the Web PKI - in one sense "Web PKI" is a misnomer because this PKI is for all TLS on the public Internet which is a lot more than the web, but in another sense it's accurate because in practice all standards development, public oversight, trust store policy setting, and so on takes place because of the Web and not other TLS applications.
PKIX Certificates - by using PKIX, the IETF's dialect of the X.509 standard, certificates actually work and have a clearly defined meaning on IP-based networks. This is a broader idea than the Web PKI, encompassing private IP networks, private CAs issuing for constrained uses, and non-TLS traffic for IP networks.
But your thrust was correct, code signing is a quite different application for X.509 certificates than PKIX, and especially than the Web PKI.
+1
I would love if my local Chamber of Commerce could give me at a reasonable price the code signing key. It's supremely weird they have to power to create the legal entity but for the little code signing key I need to find somebody in a far away country to do it.
I don't expect such a desire for state-run organizations from people in the US, but I'm surprised the whole of EU is fine with the status quo.
If their service has changed, that's a real shame :(
Email went from within 24 hours to multiple days.
Basic tasks like moving a cert between accounts are now 'it doesn't work because of a bug in our software and we have no timeline for it to be fixed'.
> including brands GeoTrust, RapidSSL, Thawte and VeriSign
The reason this was important is that Symantec's oversight had been judged lacking -- business as usual was not an option, they were asking big CAs like DigiCert about pricing for basically a white labelling service. The trustworthy CA would run everything for a few years and Symantec would own the brands while internally rebuilding to get trust back. In that discussion with DigiCert apparently just selling Symantec's CA function outright was the more attractive option than whatever eye-watering sum such white labelling would have cost.
And to be fair, when it comes to shit customer service Google would look at Symantec, laugh and say “hold my beer”.
And to be honest the parent article's main thrust comes across as "Wah, I had to pay full price" which like, I'm not even getting out my record-breaking world's tiniest violin for that, who cares?
But that's off the point. Regardless of the workarounds, whatever the goodwill DigiCert has accumulated with the developer community over the years, they are actively squandering it now and they don't seem to care.
It was still there in October. So this is a recent thing.
You are trying to be cheap while casting unrealistic expectations and executing cut-throat tactics on their chat and support.
Things do not work that way.
Either you pay a minimum, follow the rules and wait in a queue or you pay the premium to be greeted with quick turnaround and other perks.
They got to be the code signing CA by being this exact combo - inexpensive product with good support - and being granted the top link on the high-traffic MSDN page because of that. That's what DigiCert was.
Now they are suddenly 3x more expensive with comparably troublesome support.
What unrealistic expectations and who's being cheap here exactly?
Sure, some people do not see it that way, but only until the table is turned.
Edit: I am pretty sure that topic starter has Eastern European or Middle Eastern origin where being as cheap as possible is a prevalent idea. Even when it breaks people around you.
What makes you say he was "...bombarding support.."?
DNCSEC DANE TLSA is the real solution though to all public CA woes. TLSA lets you run your own private CA publicly and be trusted without root certificate stores.
What discretion the de jure controllers of .COM and .IO have, we don't want them exercising over our code. But, of course, the problem for code signing is that they'll have little discretion at all, and, were operating systems to consider switching to DNSSEC, they might as well just stop doing code signing altogether, since creating a situation where anyone can generate an authority that disables the UAC warning box defeats the whole purpose.
Code signing has always been about validating the source of a binary and that it hasn't been modified from what the publisher intended. This is done by relying on a third-party validation mechanism. DNSSEC DANE TLSA meets both of those qualifications. So does GitHub. I'd be fine with either or both as options. Microsoft owns GitHub too, so code signing could be done through that medium. Public CAs in a trusted root store allow for offline validation but let's be realistic - most devices and software are online these days and public CAs aren't particularly worthy of anyone's trust. Domain-pinning a private CA in a trust store via TLSA (or GitHub, whichever) would allow for one-time online validation and then permanent offline validation for any given binary thereby allowing device drivers to still load offline.
Microsoft unfortunately still claims that code signing stops malware. Time has effectively proven that to be false as code signing has stopped approximately zero malware infestations. Training personnel to be constantly vigilant through ongoing training modules has proven to be far more effective.