Usually, I blog to explain what we’ve just released to you. But this time, I decided to jump the gun and tell you what we’re working on right now. It makes our engineers a little nervous, but I call it “encouragement”.
In the old Symantec Partner API, we’re adding support for two new parameters that’ll make validation easier and more secure for you:
I’ve been asked many times whether we can also add the ability to define the scope of a File or DNS based Domain Control validation. It requires a lot of under-the-hood work but we have started multiple phases of this and will soon introduce these new parameters. This will let you define the domain scope just as you can already define the domain scope for Email DCV today.
Today, when you're placing a new order for the same domain, we allow you to reuse Domain Control Validation for OV and EV certificates. We can use the same DCV when the validation is still valid for longer than the certificate you are requesting. This can even lead to instant issuance, which we (and hopefully most of you) think is neat.
Sometimes you might have customers that explicitly don’t want to reuse existing DCV. Therefore, we’re adding a new parameter to disallow DCV reuse, if desired. By default, we’ll continue to reuse it – but we’ll also add the option to change the default for your account so you won’t even have to make changes to your API implementation.
We’re removing the “State” field as a requirement for Thawte certificates. None of our other products require it, and we wanted to change it before they started thinking that Thawte was being picky. Boom: certificate interpersonal crisis averted.
Ever come across a customer wanting to get a certificate for my_domain.com, or any other domain containing an underscore character? They’re not going to like this: the CA/Browser Forum is currently discussing disallowing these characters in the Baseline Requirements, and we are streamlining our internal PKI to not allow these characters anymore, anywhere.
From now on, only a-z, A-Z, 0-9, periods (.) and hyphens (-) are allowed in common names.
This has actually been the case on the Partner platform (both all portals and the APIs) all along, but we just wanted to let you know that the backend now also disallows this, in case you are able to sneak a request in through some hacky method. (Please let us know if you find any hacky methods!)
Meanwhile, as we’re continually building out the awesome new Cert Central partner platform, we’re working on Child account support, which will both support Managed Reseller accounts (formerly known as “Sub Resellers”) and Managed Enterprise accounts (which would be a similar but a heavily improved version of our previous “MSSL Reseller” system).
And in all seriousness, while that is a short statement to make, it underscores the scope and flexibility of our new platform, which our Beta participants – and soon all partners – get to enjoy.
In our targeted emails and newsletter, we’ve discussed hierarchy changes for our code signing products – particularly our intentions to issue all new code signing certificates and reissue/replace any existing code signing certs signed from DigiCert's hierarchy by 31 October 2018. Well, that date is still accurate – but thanks to some changing market dynamics, we’re required to have a plan by that date, and we won’t be retiring or migrating the current hierarchies by then. Keep an eye out for updates on this topic as things settle.
Also, we’ve updated the End of Sale (EOS) timelines for full-chain SHA-1 code signing certificates under the Symantec and Thawte brands to 31 January 2019. And if you’ve been reading all I’ve been saying (here and in previous blog entries) about the CertCentral-based partner portal, you’ll note that you’ll likely have the option of issuing DigiCert code signing certificates via the new portal by that time. As mentioned, if this date changes, you’ll be the first to know.