Yes, there's a solution to this.
Most of you guys probably won't realize, Adobe AATL is strict, which means browser downloaded certificates won't qualify for their security standard, which means all certificates downloaded directly from the browser (compare to USB token etc.) can't be included in AATL.
In Certum's case, the serial number Adobe included in the policy constraint list is their Qualified Certificate Authority (QCA) product, which is indeed based on hardware tokens. And other CAs' AATL-enabled certificates were based on hardware devices (like USB token, Smart card, etc.).
So, in short: Adobe AATL-enabled certificates are expensive and are hardware-based. So don't be a fool like me, thinking a cheap "Browser download" certificate can be used in the Adobe signing process.
Steven Zhu
shared this idea
·
@Paul Crozer
Yes, there's a solution to this.
Most of you guys probably won't realize, Adobe AATL is strict, which means browser downloaded certificates won't qualify for their security standard, which means all certificates downloaded directly from the browser (compare to USB token etc.) can't be included in AATL.
In Certum's case, the serial number Adobe included in the policy constraint list is their Qualified Certificate Authority (QCA) product, which is indeed based on hardware tokens. And other CAs' AATL-enabled certificates were based on hardware devices (like USB token, Smart card, etc.).
So, in short: Adobe AATL-enabled certificates are expensive and are hardware-based. So don't be a fool like me, thinking a cheap "Browser download" certificate can be used in the Adobe signing process.