
Steven_Madwin
Adobe Employee
Steven_Madwin
Adobe Employee
Activity
‎Aug 15, 2019
10:18 AM
Hi pingu7931, The Object Identifier (OID, the number in the Certificate Policies edit field) is a representation for a document that lays out all of the requirements of a the Sectigo AATL Policy. If the digital ID that Sectigo issued you met those requirements then they wound have include that specific OID in your Public-key Certificate (PKC), or more specifically, the Certificate Policy extension in your PKC. The missing piece of this picture puzzle is what is listed in your PKC? If you highlight your cert in the tree view on the left of the Certificate Viewer dialog, then select the Details tab, you can scroll the list view and find the Certificate Policy extension. If you click on that entry you will see a Policy OID that is a short-hand for which set of requirements your certificate met when it was issued. If it had matched the OID displayed above then the signature would have been valid. Steve
... View more
‎Aug 14, 2019
03:44 PM
1 Upvote
Hi pingu7931, This is not a Key Usage/Extended Key Usage issue, but rather a Policy Restriction issue. Sectigo recently added the USERTrust RSA Certification Authority certificate to the Adobe Approved Trust List (AATL) program, and part of the requirements of being an AATL Member is we only trust signer's end-entity certificates if they comply with a specific set of policies. If you select the top most certificate in the tree view on the Certificate Viewer dialog, and then select the Policies tab, you will see the allowable set of policies. To see if your certificate meets one of the allowable policies select your cert from the tree view (the one you redacted), then select the Details tab, and finally, scroll to and select the Certificate Policies extension in the list view on the Details tab. Granted, displaying this as an invalid signature is incorrect as it should show as Unknown because ultimately it is not valid because trust has not been established and the Acrobat should treat this the same as when trusted certificate is not found. Although I'm not sure when, there is a plan to align the two behaviors. Thank you for sharing on the forum so others can benefit. Steve
... View more
‎Apr 11, 2019
10:55 AM
1 Upvote
Hi Israr, You are correct, this is a bug. What is happening is Acrobat (and when I say Acrobat I really mean both Acrobat and Reader) validates the timestamp first in order to make sure that it is okay to use the timestamp time to perform the document signature validation. The timestamp signature is validated at the current time (all signature timestamps are validated at the current time, not just this one) which causes Acrobat to procure revocation information for both the DigitalSign Primary CA and AC Camerfirma Portugal – 2015 certificates (it’s really getting it for all four certs, but these are the two we care about in this instance). In this case Acrobat is procuring OCSP responses for both of those certificates. These two OCSP responses get loaded into Acrobat’s memory in order to facilitate signature validation elsewhere. Elsewhere in this instance is the document signature. The signer’s cert, and its issuing Intermediate CA (ICA) cert are different than what was in the timestamp signing chain, so Acrobat won’t find valid rev info in memory so it looks first in the PDF file, finds the embedded OCSP response and the CRL and uses those. When it comes to validating the next two ICA certificates it finds the OCSP responses in memory and uses those, thus eliminating the need to look in the PDF file (Acrobat always uses what’s in memory first because it is significantly faster that reading from disk). Because Acrobat never verified that the CRLs were embedded in the file it reports LTV not being enabled. The internal Adobe bug reference number is ADC-4259405. Steve
... View more
‎Apr 04, 2019
01:10 PM
1 Upvote
Responded via e-mail reply. I'm not going to post the response because it contained PII, but I can say that the crux of the matter was the non-Adobe, third-party signing application did not embed all of the necessary revocation information that is required for a digital signature to be considered Long Term Validation (LTV) enabled. Steve
... View more
‎Aug 16, 2018
03:30 PM
Hi Craig, First, the Export Security Settings feature is the equivalent of a batch export process. Each checkbox in the screen shot below used to have to be exported (and consequently import) individually. The feature was added in order to allow a user to export all of the these settings en masse. Second, the reason that the resulting security settings file needs to be digitally signed is because a digital signature provides two things; it insures that the signed file has not been tampered with (document integrity check), and, it insures that the signer is who they say they are and was authorized to sign (signer integrity check). Because we opened the door to allow a (relatively) easy way to make a lot of changes to someone's computer, it was incumbent upon us to insure that the data about to be imported provided enough security to make sure the recipient's computer was not being hijacked by an unreliable source (read, the bad guy). Finally, there is a method to allow users to import the settings without having to do anything. It was designed to work in an enterprise environment, not the individual-by-individual world (it can work that way, but as you mentioned each person has to apply the settings). You can create a custom installer that will set the registry setting to cause the Custom Import feature to be enabled. It would look something akin to this: It's from here where you can control the frequency of checking for updates and require that the security settings file is signed by a specific digital ID. I know you mentioned that you're not familiar with digital IDs, but one of the foundations of Public-key Infrastructure (PKI) is that digital IDs are only issued to entities who can prove their identity. You may want (you don't have to) require that the settings file is signed with your company's corporate digital ID as an extra layer of security. Steve
... View more
‎Aug 16, 2018
02:51 PM
2 Upvotes
Hi Loïc, Thanks for the files. Here are several takeaways in no particular order. 1) I can't help you with the iText app you are using to create the digital signatures as it's not an Adobe application. 2) LTV in General - LTV being enabled is only dependent on the revocation information having been embedded into the PDF file. The Timestamp has no bearing on LTV. 3) PAdES - Getting the digital signature to be PAdES B-T (basic - timestamped) is pretty straight forward, and it's something you've already achieved. Getting to PAdES B-TL (same as above + LTV) is not achievable because that requires the revocation information being embedded in the DSS dictionary, whereas as the current implementation of adding revocation information is to write it into the CMS package (i.e. the Contents dictionary) in the Signature Object. 4) Why no LTV for the OCSP only file - It's because there is no OCSP response to cover the ICA certificate embedded in the CMS. Yes, there is an OCSP entry in the Authority Information Access extension in the DigiCert Document Signing CA certificate, and Acrobat can get it, so why iText didn't procure it and then embed it is a mystery, but see Item 1. There is no CRL either, but I doubt you were looking for the CRL in this test. Here is what's in the CRL + OCSP file as well as the OCSP only file: 5) Why (maybe) sometimes Acrobat is reporting that it is using the cached copy of the CRL instead of an OCSP obtained in real time - That's because there is a cached copy of the CRL file on disk in the Security\CRLCache folder and Acrobat will always use a locally found piece of revocation collateral before initiating a network operation. If you delete all of the CRLs in the Security\CRLCache folder, then restart Acrobat and open the file you'll see that both the ICA and end-entity certs are using OCSP responses. 6) Why the order of file opening matters with regard to LTV, and YES it's a bug - First, it's not just Reader, this bug manifests itself in Acrobat as well. The reason it happens is the order in which Acrobat (and Reader, it's the same code) looks for rev info. The very first place it looks is in memory, because if it's there that's the fastest way to get it. If it's not in memory it then looks on disk, and failing that it will make a network call to download it. When falling through to the network call it will first try to see if it can procure an OCSP response, and if not then download a CRL. If all that fails you end up with a signature in an Unknown status because revocation checking could not occur, but that's not the issue here. The issue here is, when the first file is open (that is, one of the files without embedded rev info) Acrobat may (or may not) find a CRL on disk, and if not then it gets the OCSP response. Now the OCSP response is loaded into Acrobat's session memory. When the second file (with the embedded info) is opened Acrobat finds the rev info in memory and doesn't bother to check in the file to see if it is embedded. That caused the LTV status to be "Signature is not LTV enabled and will expire". In the interest of speeding-up the whole signature validation process we ended up losing the proper LTV status. I'll let my counterparts in Acrobat know. I hope this helps, Steve
... View more
‎Aug 15, 2018
05:04 PM
Hi Venkataswamy, For the signatures created using the digital IDs from the PKI2 environment, try the following: Open the Signature Panel Right-mouse click on the signature, and then select Show Signature Properties from the pop-up menu Click the Show Signer's Certificate button on the Signature Properties dialog Select the Revocation tab on the Certificate Viewer dialog If it doesn't mention that the revocation information (be it CRL or OCSP) "is embedded in the document" then the signature will not be LTV enabled. Let me know if it is embedded, but the signature is not LTV enabled, and then we'll go from there. Steve
... View more
‎Aug 15, 2018
04:45 PM
1 Upvote
Hi rsimpson258, Since you are digitally signing the file, as long as it's the last signature field being signed you have the option to lock the document, which effectively makes all of the form controls read-only. Select this checkbox circled below and the file will end up being read-only. Steve
... View more
‎Aug 15, 2018
04:30 PM
1 Upvote
Hi Craig, I'm not on the Acrobat team any longer, thus I don't normally monitor this forum, hence the delay in answering. First, a couple of caveats. This can only be done from Acrobat Standard or Pro. You cannot do this if you're using Acrobat Reader If you've configured Security Policies in the Adobe Experience Manager (née Rights Management Server) they are not exportable. Those policies are locked to a specific e-mail and won't work for anyone else. Please try this: Select the Edit > Preferences (Windows) or Acrobat > Preferences (Mac) menu item Select Security from the Categories list ox on the Preferences dialog Click the Export button in the Security Settings group box Click the Deselect All button, and then select the Security Policies checkbox Click the Export button on the dialog Select the None radio button on the Export Security Settings dialog, and then click the OK button Click the OK button on the no encryption confirmation dialog Click the OK button on the Save as Certified Document dialog Select a digital ID to sign the Security Settings file with and then click the Continue button Note: this works much better if you are using a digital ID that chains up to a trusted certificate that in the Acrobat list of Trusted Identities by default. Otherwise, each individual importing the file will have to manually set trust in order for the signature to be valid. Provide a name (e.g. Policies.acrobatsecuritysettings) and then save the Security Settings file Click the OK button on the success information dialog The users looking to import the file will use the same steps to get to the Security panel on the Preferences dialog, but click the Import button to start the process. You can Import using Acrobat Reader, only Export is not available. Steve
... View more
‎Aug 15, 2018
03:14 PM
Hi Loïc, Please send me a signed PDF file where the OCSP response has been embedded into the PDF file, but Acrobat is reporting that the signature is not LTV enabled. Please send the file to Steven.Madwin@adobe.com and I'll take a look. My initial guess is the OCSP response is not actually embedded, but is being procured in real time, but we'll know when I can crack the file open. <sarcasm> It's not like we've ever had a bug in Acrobat before.</sarcasm> Thanks, Steve
... View more
‎Jun 08, 2018
02:46 PM
1 Upvote
Hi mwak, Here is where we are getting into the minutia of digital signatures. It all starts with RFC 5652 - Cryptographic Message Syntax (CMS), which itself was born from the old RSA PKCS#7 specification. This spec defines how signed data is formatted. Within Section 5.3 is defined the layout of the Signer Info. The last part of the Signer Info is a section for unsigned attributes. With a regular document signature (were the signature is created by an end-user) the document's signed attributes are hashed (aka digested) and that hash (or digest if you prefer) are sent to the timestamp server where they themselves are signed. That signature (the timestamp signature) is then written into the unsigned attributes section of the Signer Info. Because the timestamp token is written into the unsigned attributes it is processed separately from the document signature, and that's why the signature validation of the timestamp is done in real time. A document timestamp signature is created in a different manner. In this case the timestamp token is part of the document signature. Ultimately, a document timestamp signature is much the same as a user created document signature, but instead of the signed bytes being signed with a user's end-entity certificate, they are signed by a trusted 3rd party timestamp server. In this case (and this is the big difference) the timestamp token returned by the timestamp server is written into a signed portion of the CMS package. An update was made to the PDF specification (ISO-32000) to accommodate a document timestamp signature that tells the validating app (in this case Acrobat, but it could be any PDF viewer that wants to do signature validation) to get the time-slice from the timestamp token in the signed attributes of the CMS package. Finally, when ETSI wrote the PAdES Technical Specification they modeled it on what Acrobat already did. They knew we didn't yet do timestamp chaining, and thus made that part of the spec recommended as opposed to required. The concept was that someday we may add timestamp chaining, but with the improvements with Acrobat's Long Term Validation signature processing it became less of a need and truthfully I doubt it will ever be implemented as there is no real ask from customers. Our engineering resources (and not just ours, but every software/hardware company in the world) are limited by time and manpower and there are other request from customers that are more pressing. Steve
... View more
‎Jun 07, 2018
12:23 PM
Hi mwak, Let's start with the ETSI TS 102 778-4 V1.1.2 (2009-12) Technical Specification. Section 4.3 recommends the validation process, it is not a requirement to be PAdES complaint. As I mentioned above, Acrobat has no notion of timestamp chaining. That is, a new timestamp cannot be used to validate an earlier timestamp. Each timestamp stands unto itself. When it comes to validating a timestamp (also noted above) the timestamp time cannot be used to validate the certificate chain used to create the timestamp signature. Thus, Acrobat (and Reader) must procure revocation information in real-time to validate the certificate chain used to create the timestamp. The timestamp time is used to validate a document signature, but not itself. Signature validation is really a two part operation. First, the integrity of the document is validated by making sure the signed bits match the current bits listed in the signed byte range (which defines that portion of the document that was signed). There is no time involved in that part of the signature validation. The second part of signature validation is checking the integrity of the signer. There are a lot more bits of minutia that are involved in the signer integrity check than there are in the document integrity check. The first thing that has to be establish is the signing chain must be built. Then the signing chain is checked to see if any of the certificates in the chain have been designated as a trust anchor. Without trust nothing else happens. Once trust is established then a time-slice to use for validation has to be defined. This is where a timestamp comes into play. If the document recipient has chosen to do validation at the current time, then they use the time from their own computer. If they have chosen to validate the document signature at signing time then the timestamp time is used if it is present. At some point in all of this the certificate used to sign the timestamp token (which contains the timestamp time) has to be validated. This always happens at the current time as the timestamp authority cannot use their own time to validate their certificate chain. There are Acrobat preferences to not throw out the timestamp token if the cert validation cannot be done. This is why when you move the clock ahead to a point past the time those certs have expire the timestamp is not invalidated and tossed out. There are rules that state that a certificate authority is not required to provide revocation information on an expired certificate (otherwise the certificate revocation lists would grow to an unwieldy size). Because of this Acrobat cannot trust that just because an expired cert is not on the CRL that it was not revoked at signing time. With document signatures, once the signing cert has expired, if the revocation information that was used as signing time was not embedded in the PDF, then the signature changes to an Unknown status. With a timestamp signature we don't do that, when they expire we just ignore doing revocation checking and continue to use the timestamp's time-slice to validate the document signature. Steve
... View more
‎Mar 22, 2017
07:09 PM
1 Upvote
Hi Enric, With regard to your private message, I got the file you posted. Three things: The signatures don't look like they were created with Acrobat or Reader. When it comes to third-party signature creation apps there is not much I can help you with as far as how the signature gets created. In order for Acrobat to recognize the signature as being PADES compliant the /subFilter must be set to /ETSI.CAdES.detached, whereas the /subFilter value in the file you posted is /adbe.pkcs7.detached. That just gets Acrobat to check the PADES compliance level of the signature. Then, in order for the signature to meet the Basic compliance level the CMS object must conform to to RFC 5035. Additionally, if the signature is going to be -L compliant (Long Term Validation) the revocation information must be embedded in the DSS (this part you've got). Finally, if the signature is going to be -T compliant it must be timestamped (and again, this you've got). A timestamp is always validated in real time, it can't rely upon itself to provide the revocation time-slice. I noticed that you added a document timestamp about 35 minutes after the document signature was created. My guess is you were trying to see if Acrobat would pick that time to do the revocation checking on the signature timestamp, but as you found out it did not. Acrobat does not have the concept of timestamp chaining, and thus each timestamp signature is independent of all other signatures. Steve
... View more
‎Jan 23, 2017
02:10 PM
Hi Enric, Do you have access to the file and if so, is it allowable to send it to me (that is, it doesn't contain any proprietary information)? Steve
... View more
‎Mar 17, 2016
12:29 PM
Hi Neerja, I'm not quite sure what work-flow you are using, but here's my guess. If you are dealing with a document that does not contain any existing signature fields, then when you initiate the signing process Acrobat will ask you to draw (inscribe) a field somewhere on the document. After you draw the field, but before you proceed with the signing operation you have one signature field. You may consider it the first signature field, but it is also the last signature field on the document. When a signer is signing the last signature field, and only if it is the last signature field Acrobat will offer the signer the option to lock the document after signing (see screen shot below). If there are still unsigned signature fields on the document the Lock Document After Signing checkbox is not displayed. It is possible that your boss is selecting this checkbox thereby blocking you from signing, but when you sign you are leaving the checkbox deselected, thereby allowing him to successfully sign. If there are existing signature fields that were placed on the page(s) by the document author (creator) then it is possible that there is associated code with one of the fields that locks the document at signing time, but without seeing the file, or watching over your shoulders, this is all just speculation on my part. Steve
... View more
‎Nov 18, 2014
10:55 AM
Hi Laurent, The lack of the EKU extension does NOT prevent signing in Acrobat or Reader. When the certificate authority (CA) issues a certificate, they have certain controls as to how to limit the use of that certificate and those controls are the extensions that they may add to the certificate at cert creation time. However, there is nothing that says they have to limit the usage. If they (the CA) elects not to added any limitations then the certificate is considered good for any and all digital signature based operations. At a minimum, there is one limitation that always is placed on a certificate, and that is its validity period. No matter how long you make the life of the certificate it will expire at some point at which point it has reached a time limitation. Other that the expiration date there are other items that the CA may add to the cert in the form of extensions that tell the processing application (in our case that would be Acrobat & Reader) how to limit the use of the cert. It's not just the KU and EKU that can limit the use of a cert. For example there are constraints (path, name, basic) and policies which would also limit the use of the cert. With regard to the KU and EKU, the CA doesn't have to add either of those two extensions, but if they do it is incumbent Acrobat and Reader to respect the limitations the CA has imposed. If the CA adds the KU extension, then that particular extension must contain either the "digital signature" or the "non-repudiation" value in order for the cert to be considered good for signing a PDF file. Other values could be included in the KU, but at a minimum one of those two I listed must be present. They can both be there as they are not mutually exclusive, but at least one of them has to be there IF the KU is included in the cert. If the CA adds the EKU extension, then that particular extension must contain either the "any allowed", "e-mail protection", or "code signing" values. Again, and like the KU, any one value will suffice, and they can all be there, but at least one of them must be included in the EKU. Steve
... View more
‎Nov 12, 2014
10:08 AM
1 Upvote
Hi diber001, If the PDF file already contains a signature field, then the author of the document expects you to sign using a certificate (that is, create a cryptographically secure digital signature) and not use an annotation based unsecured electronic signature, and thus, all of the other options on the Place Signature dialog are disable other than the Use a certificate option. Steve
... View more
‎Nov 05, 2014
10:08 AM
2 Upvotes
Hi Milos, Correct, Client Auth does not enable the cert for PDF signing, and for that matter neither does Smart Card Logon . There are a a lot of little bits to consider. A certificate with neither the Key Usage (KU) extension nor the Extended Key Usage (EKU) extension is to be considered good for every and all possible operations that a certificate can be used for. Once the certificate authority (CA) adds one, or both, of those two extensions they are in essence limiting the use of the certificate. Where things get a bit messy is coming to the realization that the two extensions (KU & EKU) are processed separately. Both (if they are both present) must allow for signing a PDF, or more correctly, neither must disallow signing a PDF. In the case of your certificate, the KU does allow for signing a PDF because it has the "Digital Signature" value, but the EKU does not allow for signing a PDF because it does not contain one of the three values (Allow Any, Email Protection, or Code Signing) that we require. At least one of those three values has to be there if the EKU is present for the certificate to be able to sign a PDF file. All of these rules are defined in the internationally accepted standard RFC 5280, sections 4.2.1.3 & 4.2.1.12. Steve
... View more
‎Oct 30, 2014
01:25 PM
Hi rennels, I understand what you're saying that it doesn't make sense that you can see the bottom buttons, but not the password confirmation field. It's a bug in how the dialog is drawn. Please try a slightly higher screen resolution and let me know if that brings up the missing password field. Thanks, Steve
... View more
‎Oct 30, 2014
10:43 AM
Hi rennels, The bug was that the Add Digital ID dialog did not scale correctly on a laptop running a display resolution less than 1024x768, hence the second password edit field doesn't display correctly. Try running in a higher display resolution, or using a computer with a larger monitor. Steve
... View more
‎Oct 02, 2014
01:06 PM
1 Upvote
Hi Eric, The first two items (and I'm going to do this in English) ; Sign Transaction, and Sign Document are from the Key Usage extension (they represent the "digital signature" and "non-repudiation" bits respectively). Their presence limits the use of the digital ID to signing anything other than certificates and CRLs. If there was no Extended Key Usage (EKU) extension present you would still be able to sign a PDF file. However, the last item on the list (Client Authentication) is from theEKU extension and it tells the processing applications (in our case Acrobat & Reader) that the digital ID is further restricted to allowing the client (in other words, your computer) to authenticate to a server or system. A bit about digital IDs. They are issued by trusted third party Certificate Authorities (CAs) and it's the CA that determines for what purpose a digital ID that they have issued may be used. The CA controls what goes into the usage, constraints, and policy extensions, and together those extensions define and narrow the purpose a the digital ID. The CA is governed by a set of policies and practices that are defined in publicly available documentation, and their whole existence is dependent on not varying from those rules. If they say (through the cert extensions) that they want the digital ID limited to a particular operation then it is incumbent on the processing application (again, in our case that means Acrobat and Reader) to respect those limitations. Yes, Acrobat used to ignore the EKU and that was a flaw in Acrobat. As you may imagine, ignoring the EKU caused problems for certain users and thus brought this flaw to light, which is why it was fixed in version 11.0.9. The bottom line is, you need to coordinate with the CA that issued you your certificate and procure a new digital ID that is not restricted to client authentication. The three things that may be in the EKU that would allow signing of a PDF file are ; Allow Any, Email Security, and Code Signing. If the CA were to add one of those to the EKU along with Client Authentication, then you will be able to sign again. Steve
... View more
‎Oct 01, 2014
01:00 PM
Hi sign forms, Proviso: This is harder without Acrobat to do some editing and image-to-PDF conversion. Let's start with the infrastructure of a signature appearance field. The field has two layers, a background and a foreground. The foreground is additionally divided in half with the left half displaying graphics and the right half displaying text. If there is no graphic as part of the signature appearance then the whole of the foreground becomes one big text field. The same thing applies going the other way, if there is no text then the whole of the foreground becomes one big graphics field. The default background is the pink PDF trefoil logo. You have an option (we'll get to it in a bit) of not displaying the background at all, but you also have the ability to change the background image. If you want to use your own logo you need to put it in a PDF file, name the file SignatureLogo.pdf and save it to C:\Users\<user name>\AppData\Roaming\Adobe\Acrobat\11.0\Security\. You would want to crop the PDF page (you need a PDF editing toll such as Acrobat, you can't do this in Reader) so it is pretty much just the image, otherwise the logo will be too small when displayed in the signature field. To create a custom foreground appearance follow these steps: Select the Edit > Preferences menu item Select Signatures from the Categories list box Click the More button in the Creation & Appearance group box (the topmost button) Click the New button in the Appearances group box Here is another place you are going to be limited as a Reader user as you can only import a PDF file as an imported graphic. Reader does not have the ability to process image files like Acrobat does, thus all you can import are PDF files. It's on this dialog that you also have the ability to turn the background on & off via the Logo checkbox. As you turn items on and off you will see the Preview box reflect the changes. Here's an example of where I changes the background to a picture of a rubber duck, made the left side of the foreground a scanned image of my wet ink signature, and made the right side (the text side) of the foreground only have the Date and Version number: Steve
... View more
‎Oct 01, 2014
12:14 PM
Hi Eric, One thing that since the beginning of digital signatures in Acrobat/Reader the app didn't process the Extended Key Usage (EKU) extension, but that was remedied with version 11.0.9. Now, in order to be able to use a digital ID for signing a PDF file, the digital ID must not be limited to its use via the EKU. My guess is (and since this was the only change to signing in 11.0.9), you are trying to sign with a digital ID whose purpose has been limited by the issuing CA because they add a value to the EKU. Please follow these steps to get the usage setting and then let me know what they are: Select the Edit > Preferences menu item Select Signatures from the Categories list box Click the More button in the Identities & Trusted Certificates group box (the third button from the top) Highlight your digital ID in the list box and then click the Certificate Details button on the toolbar Highlight the text in the Intended Usage field on the Certificate Viewer dialog and copy the text You can then paste that text into your reply and I can then explain why the digital ID is not allowed for signing. Steve
... View more
‎Oct 01, 2014
01:14 AM
Here are some links that explain the process: 4 Custom Signature Appearances — Digital Signatures Guide for IT http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&ved=0CEwQFjAE&url=http%3A%2F%2Fwww.post.trust.ie%2FDownlo… http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=7&ved=0CFgQFjAG&url=http%3A%2F%2Fgeminisecurity.com%2Fwp-co… Adobe Acrobat X Pro * Setting up signing https://acrobatusers.com/tutorials/how-do-i-add-a-scanned-signature-to-a-digital-signature http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=10&ved=0CGoQFjAJ&url=http%3A%2F%2Fwww.chaffey.edu%2Fcsn%2Fp… Steve
... View more
‎Sep 30, 2014
05:10 PM
Hi Sign Forms, You definitely don't want to create a digital ID if what you are looking for is an electronic signature. You, like Greg above, seem to be in a situation where the Place Signature default is locked onto the certificate based digital signature workflow. Follow what I mentioned directly above and see if that gets you into the desired state. However, and as an aside, should you ever decide to adopt the use of certificate based digital signatures for security purposes there are options to customize the signature appearance so it does not display the block letters you mentioned. Steve
... View more
‎Sep 30, 2014
05:03 PM
1 Upvote
Hi Greg, If upgrading from and earlier version of 11 to 11.0.9 caused the Place Signature tool to lose it's settings that would be a bug. I'll see if I can reproduce that behavior. That said, it seems that Place Signature now thinks it's default setting is to create a digital signature whereas you want it to be an electronic signature. What you need to do clear the settings and reset the default by selecting the drop-down menu just to the right of the button proper, and then select Change Saved Signature from the drop-down menu. That will allow you to chose a different option than a certificate based digital signature. Steve
... View more
‎Sep 30, 2014
02:38 PM
Hi Greg, There a couple of different concepts that I fear are getting merged into one generic "signature" conversation blob. Let me start with some definitions: A digital signature - A cryptographic operation based on using a digital ID that provides both proof of document and signer integrity. The actual signature is a blob of encoded and encrypted data written into the PDF file, but it may reference a field in the document that is a graphical representation of the signature, and is known as the signature appearance. An electronic signature - An imaged added to a page in the PDF file that is a graphical representation of a "wet ink" signature. There is no cryptographic assurance that the signature is valid, or, what has purportedly been signed has not been altered. What you see on the page is all there is and there is no validation to check integrity. It sounds like you were using an earlier major version of Acrobat or Reader (by major version I mean the "11" part of 11.0.9. The zero dot nine is the minor version) and when you upgraded to version 11 (or XI as you see it in the marketing branding) you lost the link to the image file you were using in version 10 or earlier. It seems to me (correct me if I'm wrong) that you are trying to create an electronic signature with a image file that had the background opacity set to 0% so the background of the image did not obstruct the view of the text on the page. If you don't know where the original image file is you're not going to be able to use it in version 11. If you do know where it is you can do the following: Open the Fill & Sign pane on the toolbar Expand the Fill & Sign Tools panel Mouse over Place Signature and then select the drop-down menu by clicking the down-arrow button on the right Select Change Saved Signature from the drop-down menu Select the Use an image radio button Click the Browse button to the right of the File Name edit field Navigate to, and select the image you would like to use, and then click the Open button Click the Accept button on the Place Signature dialog At this point your mouse cursor is your signature. Click on the page wherever you'd like the electronic signature to appear and Acrobat will then revert to the normal editing mode. Steve
... View more
‎Sep 30, 2014
01:36 PM
1 Upvote
Hi, I assume when you say "another pop up" you really mean that your seeing this dialog... Let's start with some nomenclature so we are on the same page. What you are trying to do is create a "digital signature" and in order to do that you need a "digital ID". To think of this in physical world terms, the PDF file is a piece of paper, the digital ID is the pen and the digital signature is, well the signature. In order to create a digital signature you must have something to sign with, and that something is a public-key based digital ID. This digital ID can reside in several places. It can be in a password protected file and the file would have either P12 or PFX as the file extension to the file name. The digital ID could be locked onto a token or smart card, in which case you would get access to it using a PIN instead of a password. It could also be locked into the Operating System. On Windows that would be the Windows Certificate Store (think of "store" in this case as storage, not a market place), and on the Mac it would be the Keychain Access application. So the question is, do you currently have a valid digital ID (they do expire) or do you need to procure one? My guess is you need to procure a new digital ID and this is where you are being tripped up. If you do need to procure a new digital ID, the next question is, do you need to get a high assurance digital ID from a trusted 3rd-party Certificate Authority (you, as the signature creator are the 1st party, and whomever you send the signed PDF file to is both the signature recipient, and also the 2nd party). The thing that makes a Certificate Authority (CA) trusted is because they will do identity vetting in order to ensure that you are who you say you are before they issue you a digital ID. When you get a digital ID from a CA you can think of it as a drivers license or password, not for what they allow you to do (drive a car or cross a border), but rather as a trusted and generally accepted piece of identification. Yes, a digital ID issued to you from a CA allows you to sign data just like a pen, but more importantly it acts as a trusted piece of identification. All that said, if you don't need a high assurance digital ID that proves you are who you say you are, then you can create your own digital ID. In that case the digital ID is really just a pen for signing and does not provide any trust regarding your identity. The advantage to creating your own digital ID is it's quick, easy, and free. The downside to getting a digital ID from a CA is it is time consuming and not free. Since your have started down the path of creating your own digital ID already let's finish with that workflow and leave it for later to see if that meets the identity requirements of whomever you are sharing the signed file with. If you are seeing the dialog above select the bottom radio button next to "A new digital ID I want to create now", and then click the Next button. The contents of the next dialog you see is as dependent on whether you are on Mac or Windows. On Windows the next dialog asks you where you want to save the digital ID, either in a password protected file, or in the Windows Certificate Store. If you select the File option you will be asked to provide the password every time you sign a PDF file, whereas with the Windows option when you log into Window that provides the authentication to access the private key in the digital ID and thus when you sign a PDF file you won't be asked to provide a password. If you are on a Mac since saving the digital to a file is the only possible option this dialog is skipped. The next dialog is where you enter the information that you want contained in the digital ID that identifies you as the signer. If you've already filled out the Identity panel on the Preferences dialog then that data will be pulled in, but if not you you are going to need to add at a minimum a Name and an Email address, and then click the Next button. If you are saving the digital ID in a file, the next order of business is to pick a location where you want to save the file you are about to create and assign it a password to protect the private key from unauthorized access. You're now on the last dialog for digital ID creation so you can click the Finish button. This takes you to the Sign dialog. If you already had a valid digital ID to sign with you would have seen this dialog right after you inscribed the signature field and would have shipped all of the digital ID creation dialogs. If you saved your new digital ID in a file the Sign dialog will ask you to provide the password you just used (don't forget this password because you'll need it when you want to sign files at some later date). Enter the password and click the sign button. You'll be asked where you want to save the signed file (you can overwrite the existing file if you like, or you can save it as a new file), and once you've done that you'll have a digitally signed PDF file. Steve
... View more
‎Sep 30, 2014
10:49 AM
Please let me know which dialog you are seeing. Is this the dialog you are seeing? Figure 1: Place Signature Or is it this dialog? Figure 2: Drag New Signature Rectangle Thanks, Steve
... View more
‎Sep 29, 2014
10:41 PM
Hi, Let's start with what application you are using (it's not Adobe because Adobe is a company, not a product). Is it Acrobat or is it Reader? If you are on Windows you can get the information from the Help > About <application name> menu. On the Mac it would be the Acrobat or Adobe Reader menu and then About <application>. Once you get the about screen up you will see a version number. If you can let me know what that is as well that would be great (I know you said the major version is 11, I'm also curious as the the minor version number). Thanks, Steve
... View more