I am having following doubts regarding digital certificates -
In the property pages on windows OS we see Digital signature Tab. In
that tab we see digital signature list. If we select any one from
that list and checked the details of it looks like shown below.
I would like to know what is exact differences between the two
highlighted sections(Signer Information and Countersignatures) in
the image that is shown?
If anyone want to verify this executable which certificates or
certificates chain needs to be present in his/her certificate
stores? I see different certification chain for counter signature certificates.
Anyone may download and see this executable from following link -
https://www.veritas.com/content/support/en_US/vqa.html
As per MSDN https://learn.microsoft.com/en-au/windows/desktop/SecGloss/c-gly
countersignature
A signature of an existing signature and message or a signature of an
existing signature. A countersignature is used to sign the encrypted
hash of an existing signature or to time stamp a message.
Yes the certificate chains may be different.
Related
Issue:
I have created a new template for Web Servers and if I use the MMC Snap-In called "Certificates", then select "Local Machine", the snap-in comes up. I then follow the UI and can clearly see my template and am able to successfully enroll via AD and my certificate installs with no problem.
The issue here is that when I do the above, the certificate is good for 2 years (just like I set it in the validity period). However, I am trying to script this process and "Get-Certificate" kept giving me an error I couldn't figure out so I am using the "certreq" command line tool.
When I use this tool, I am able to get a certificate but its validity period is set to 1 year instead of 2. I get this error every time (even when I use Admin account on the CA or Sub-CA):
"The certificate validity period will be shorter than the Web_Server-Primary Certificate Template specifies, because the template validity period is longer than the maximum cer
tificate validity period allowed by the CA. Consider renewing the CA certificate, reducing the template validity period, or increasing the registry validity period."
I have checked and re-checked the validity period and still can't get this to work. I have done this now many times and every time I use MMC, it works like it should. But when I use "certreq", I get the error. I also specifically state which Sub-CA to use to ensure the processes are as identical as possible.
Has anyone had to deal with something like this before?
We're using ruby-saml to establish our app as a service provider while using Google as an identity provider, though I do not think this question is specific to Ruby or that project.
I have seen this answer from the point of view of an IdP, but I'm hoping to see one from the point of view of an SP, because I have a hard time believing Google is getting the signature on the response wrong.
On top of that, we have successfully integrated with other Google accounts, and they work at the same time this one is broken.
As the service providers, how can we figure out the source of an Invalid Signature on SAML Response from the identity provider?
We had same error, but different solution. Our problem was invalid characters in the xml response. Both parsing and validation failed. We could substitute the chars before parsing, but then the validation would still fail because of the changed content. The solution was to base64 decode the response, and open the xml response in an editor (or online xml validator) to find the problematic data. In our case: attribute name "objectSid" from AD. We then changed the simplesamlphp config so that it sent only the data we needed. Now the response validates and parses without problems. Btw in "settings.idp_cert" (using ruby-saml gem) we include both the "begin certificate and end certificate headers".
Also there are browser add-ons that will intercept the saml conversations for debugging purposes.
Also check this for online troubleshooting:
validate response:
https://www.samltool.com/validate_response.php
(be careful not to paste your private keys online. only public cert is needed for response validation)
validate xml:
https://www.xmlvalidation.com
online base64 decode:
https://www.samltool.com/base64.php
I ended up using the suggestion to use XMLSec in the answer I referenced in the question, and ran through the decoded base 64 response and the certificate(s) in the metadata file from Google.
That gave me the confidence that there was indeed something wrong with the certificates in the IdP metadata XML file that Google provided.
I then noticed that my working accounts only had 1 certificate in the file, while this one had two. So I removed one, and it did not work. Then I replaced it and removed the other, and it worked.
Then I found out that I could place both certs in the file as long as the working one was first.
I am not sure why there was a difference, and I do not know why Google outputs the certs in an order that XMLSec cannot use to verify the signature.
Perhaps someone with more knowledge than myself can chime in on that, but for now, I'm happy to report that simply reversing the order in which the certs appeared in the IdP metadata file from Google allowed the signature to be verified.
I needed to include this setting as well. YMMV, seems like the default algo is sha1, but the key and output that i was calculating using the openssl utility was using sha256:
settings.idp_cert_fingerprint_algorithm = "http://www.w3.org/2000/09/xmldsig#sha256"
In the CA I'm working on, we have certificate templates that are used to configure CSRs on various devices. We need to keep track of which template we push to a device, so that we can validate the CSR against the template used. For iOS devices, we're thinking of including the template name in the "Name" field for the SCEP Payload. However, I'm not sure how this field is packaged into the CSR that the iOS device creates. According to the OTA Configuration Guide,
The service can provide different certificate issuing services parameterized on the Name value that becomes part of the final URL. In the case of Windows, this value needs to be set, although any value will do.
This is the only indication of how this Name key/field is used. Does anyone know what becomes of this key? Is it made into an attribute in the CSR? This quote says it "becomes part of the final URL." Does this mean it's injected into the SCEP URL? There doesn't seem to be much documentation on this.
I am working on creating a PDF file which is digitally certified/signed. I am successfully able to sign my pdf document, using itext library.
However, the certificate details on the adobe reader shows me as below:
Is the certificate ok? or is there any issue with it?
Is the certificate ok? or is there any issue with it?
As far as your PDF viewer is concerned...
The certificate obviously is ok as far as your Adobe Reader is concerned. Your screen shot
contains this document status in the document message bar:
According to the Signature Validation guide by Adobe
this means two things:
Document has not changed or only contains permitted changes. (Document integrity check)
[Identity] Verified for all signers. (Identity Check)
In particular the latter means that Adobe Reader sees no issue with your certificate.
In the Certificate viewer this is confirmed by
Your certificate is trusted to sign documents or data.
... but what is its legal value?
This is a different question altogether.
You already mention one obvious issue in a comment,
however I have used my SSL certificate for signing
in particular the subject of the certificate essentially only is your web site. That web site definitively is no natural person and most likely (I don't know Indian law) not a legal person / corporate body either. Thus, it isn't even clear who signed in that signature to start with.
Furthermore, SSL certificates usually probably have a key usage attribute value "digital signature" but not "non-repudiation". Thus, all it expresses is "this is a document as I saw it" (as long as the signature is not broken) but definitively not "I am responsible and liable for its contents".
In general, depending on the context the legal value is considered for, there are many countries and associations of countries which have strictly defined requirements for digital signatures to have immediate legal value, e.g. in the EU the eIDAS regulations. As you appear to be interested in India, Aadhaar certificates by the UIDAI might be more appropriate.
On the other hand, if you have agreed with the recipient of your signed document beforehand that you will use your SSL certificate for binding signatures, chances are that such signatures eventually are recognized as legally binding, too, and you can be held liable in court for what you signed.
Building an iPhone OS application that will allow users to anonymously post information to a web application (in my particular case it will be a Rails based site) ... and I want to ensure that I only accept posts that originate from a specific application running on an iPhone/iTouch.
How is this best accomplished?
(btw, if your answer applies to Android please feel free to post it here as well as I'm curious to know if the techniques are the same or vary).
Thanks
The best way would be to implement a known call and response pattern. Send a value of some sort (integer, string, hash of a timestamp) to the iPhone/iTouch application. Have the application modify this information in a known way and send it back for verification. Then all you have to do is use a different modification algorithm per-platform and that will verify what type of device is being used.
VERY simple example:
Server sends 100 with the response to an iPhone.
iPhone adds 10 to this value and sends back with request.
Server detects the value was increased by 10 and now knows it was from an iPhone.
Then on your Android clients add 20 and on another platform add 30 and so on...
You could also add a hidden field in the form. or in the data being passed up if it is XML or other format
Encrypt or sign something using the public key of a key pair, then decrypt or verify it on the server with the private key. Ultimately, anything that can be sent can be duplicated, be it a spoofed html header or an encrypted block. The app has to know the secret handshake, and anyone with access to it (and sufficient technical skills) can figure out the secret handshake.
I would suggest the following approach.
Build an ssl enabled access to your rails app.
Now create a user account for every plattform you want to use and enable your applications to log in with the correct key. If you use the ssl standard in a correct way there shouldn't be a way to sniff the password and you can use standard components on the rail and the phone side of your app.
You then need to secure the login credentials on your phone with the appropriate technics. Eg. put it in the keychain on the Iphone.