I have 2 code signing certificates, for both CSR is created same way, also import and export is done same way. The only difference that I see is that one of certificates Common name contains Quotes, and the other doesn't.
e.g.
some cert and
some "cert"
CSR creation
Request format PKCS #10
disabled "Strong private key encryption"
Entered Common name, Organization, Locality, State, Country
2048 bytes for private key
set private key exportable
Import
place all certificates in Personal store
Export
Include all certificates if possible
Enable certificate privacy
encryption algorithm TripleDES-SHA1
Misleading thing is that this Common name value is NOT taken from the value I entered when I created CSR request
I am using those certificates to sign Winforms applications in Visual Studio. Certificate without Quotes in common name is working correctly (i.e. when I install application user is not getting security warning about unknown publisher), but when I install application which is signed with the other Code signing certificate (with Quotes in Common name) - it does not recognize Publisher. No error when published my application. When I take a look at setup.exe properties in Windows Explorer I see a Digital signatures tab which contains row for my certificate.
I tried to sign files with signtool and then verify - it said that certificate is valid.
I tried to get help from godaddy.com where I bought my certificate, they said that it should work with quotes, too, but didn't offer help to solve the issue. Rekey also didn't help.
I see that there are some suggestions to use Pre Publish, Post Build tasks, but I am not using those for my first certificate which is working.
So, is anyone here using code signing certificate for Winforms application with common name having quotes in it? Or maybe anyone knows about this problem and how to solve it?
Had to revoke (common name which is entered when creating CSR is not taken into account, so rekeying is not enough!) my code signing certificate and create from start without quotes/brackets in company name.
So this means, you will have to wait again for few days, because verification process is made from start again. When you will be contacted by issuer, they will verify / ask you about company name - make sure that they do not include quotes/brackets.
Revoking means that you will basically have to buy your certificate once more, because after you revoke it (at least in godaddy case) in your account you don't have options to create it again. So, you have to contact support (use call center and not chat ;)
Related
I am using a certificate to sign a jar file. Jarsigner is able to add the signature and it verifies without warning. This is done on a Windows machine. However, on Android, when I try to verify the certificate used to sign the jar file, it reports that only a partial chain is found. The certificate used was issued for signing by a CA. The root certificate is on the Android device under the system security certificates tab. The intermediate certificate exists in the security certificates user tab as I had to add that manually. Part of the process involves my copying the AndroidCAStore and passing the certs to another assembly where I have tried to use an X509Chain, cert.Verify(), and Bouncy Castle to verify the chain. All three methods fail. I am not finding a lot of clear information on how this process should work, but I've checked the store being passed into the verification method and both the intermediate and root certs are there. The intermediate cert gets added to the chain, but never the root. What may I be doing wrong here? The code is all C# if that helps.
I am trying to recreate a Developer ID Application certificate, so I can sign my application. I had an existing certificate, but it's about to expire, so I am trying to regenerate a new one.
However, when I download a newly generated certificate from developer.apple.com, the imported certificate has no key as its child node in Keychain Access. The old certificate had this. When I attempt to use the certificate for code signing I receive something like:
/tmp/myapp.app/Contents/app/bin/myapp.exe: errSecInternalComponent
I am following the instructions to obtain a signed certificate using Certificate Assistant:
Ensuring nothing is selected in Keychain Access, click Keychain Access > Certificate Assistant > Request a Certificate from a Certificate Authority.
I enter my email, accept the default Common Name and click Saved to disk.
In developer.apple.com I click the "+" to Create a New Certificate
I choose Developer ID Application
I upload the CSR I saved above
I download the .cer file that is generated
I open the .cer file. This adds the certificate.
As you can see, the certificate does not have a private key inside it, like the old one:
Unfortunately I don't have the old certificate now having deleted it in a fit of pique but it looked like this:
... although in my case it had my private key.
I've noticed reference to the claim that creating a CSR also creates a public/private key pair, but I cannot see these anywhere in Keychain Access.
Later, I did manage to import the certificate and it show the private key. I think this was when I imported it into the same keychain as that which contains a private key "Dan Gravell" - login. However, I have since tried replicating that and now the certificate is being imported without a key again.
Xcode appearance
I've discovered there's a little more information in Xcode. The certificate shows "Missing Private Key" next to it:
When I look this error up, the suggestions seem to be that the certificate has been given to a developer by some third party that didn't include the private key. However, in my case I am that third party who has created the CSR and received the certificate originally and I thought I had the private key, otherwise I wouldn't have been able to create the CSR in the first place. All these items appear to be in my keychain.
I (eventually) got a reply from Developer Program Support. They issued a new certificate which I installed via XCode this time. I documented my other steps here: https://stackoverflow.com/a/74210449/28190
As I can see, in Windows, the Digital Signature tab of an EXE file will show the Company Name, City Name, and Country Name of the company.
Is the user able to find the detailed address of the company from the signature? The situation is the same for OV and EV code signings?
Thank you.
Information appearing on the Digital Signature tab come from the 'Subject' field of the certificate.
This information is provided by the company when signing keys are generated.
Then, those keys are used to generate a Certificate signing request (CSR) who contains this information + public key.
This is this CSR who is transmitted to the certificate authority.
The certificate authority will then sign digitally the certificate with his proper key, after validation of information present on the CSR. It will not add any further information about the company, only validate and sign. The validation process of the company by the authority will be different for OV or EV, but information present on the certificate stays those provided by the company on the CSR.
The detailed address of the company will appear only if it was provided when signing keys were generated.
This is not typical information required on a certificate, but the company can choose to add personalized information on the Subject field.
I am not aware of any certificate authority who require the detailed address on CSR.
I don't believe so as it would not be very secure to display the company's detailed information. This could lead to someone breaking in or harassing workers where Microsoft could be blamed as they let the company's address go public.
Data about an exe file made with visual studio is created like this inside the AssemblyInfo.cs (in C# projects) in the properties. This is all the data that can be found if I'm correct. Every application made in visual studio will have something like this, I'm not sure about C++ projects, but it should be something around the lines like this.
we developed an app for WP8 and wanted to distribute it internally via a download URL to the XAP file. Steps we have taken so far:
Use Makecert.exe to generate a self signed XXX.cer with a XXX.pvk (with no password)
Used Pvk2Pfx.exe to create a pfx file which includes the private key (with a password)
Used XapSignTool.exe to sign our XXX_Release.xap
We also deployed the XXX.cer to the phone device but we still get the error "Can't install company app".
After that we tried to generate a Application enrollment token (AET) with AetGenerator.exe (not 100% sure if we do need this) from out XXX.pfx which exits with an error:
Unknown error while generating AET startIndex cannot be larger than
length of string. Parameter name: startIndex
Any ideas what we are doing wrong or suggestions what would be the way to distribute an app like that? Is it only possible if we have obtained a certificate from Symantec?
Thanks!
PS: I just browsed throught the MS Documentation and for the PFX parameter of the AETGenerator it states:
Required. The name of the PFX file generated from the enterprise mobile code-signing certificate provided by Symantec.
So most probably it seems that a Symantec $299/year certificate is required. Would this be the correct assumption?
It was indeed as it seemed. You can sign you code with any self signed pfx generated after the latest documentation on the pfx tool.
It is not possible to deploy an App without a company account. This involves paying the $299 and going through the certification process by Symantec.
I'm trying to create a test certificate and sign a .MSI file I have created. I need to get the test version working with a signed .MSI before we can purchase a real security certificate.
I have performed the following steps to sign my .MSI file. Everything completes successfully and it displays a message that 1 file was successfully signed after the last step.
makecert.exe -sv c:\Test\mykey.pvk -n "CN=WTS" c:\Test\myCert.cer
cert2spc.exe c:\Test\mycert.cer c:\Test\mycert.spc
pvk2pfx -pvk c:\Test\mykey.pvk -pi password -spc c:\Test\mycert.spc -pfx c:\Test\mycert.pfx -po password
signTool sign /f c:\Test\mycert.pfx /p password /v c:\Test\test.msi
After performing these steps, I run the .MSI file (the date modified for the .MSI does change to match the time the signTool step was ran). The warning message saying this .MSI is from an unknown publisher is still displayed as is "Publisher: Unknown".
Did I miss a step or something? Everything seems to work correctly, I never see any errors, but my file doesn't appear to be signed.
Your file is signed. Windows declares the publisher as unknown because it does not trust the publisher identification in the signature.
Remember that in the world of digital signatures, you always need to verify at least two things at once or the whole exercise is meaningless. You must check the name on the signature, and you also need to find a trust link from something that you already trust (for example, a certification authority, or a certificate manually added as trusted) up to the signature that you are checking. Only then it makes sense to trust the name on the signature, and perhaps to display it to the operating system user.
In your web browser, go to Tools / Internet Options / Content / Publishers / Certificates and add your test certificate to Trusted Publishers.
(Another browser might have the same function under Settings / Show Advanced Settings / HTTPS/SSL / Manage Certificates.)
And retry. It won't work but I don't really know why and it is an instructive game.
It is not clear whether there is a way on Windows to establish a chain of trust if your certificate is home-made and there is no certification authority to back it. This source says:
If you use a test (self-created) certificate, the installation dialogs
will display an "Unknown publisher" message. For applications deployed
internally in an organization, this is an acceptable practice."
You can however create your own certification authority as described here and add the CA certificate under the Trusted Root Certification Authorities. By doing this you are basically letting any certificate issued by that CA sign anything and be trusted by Windows.
I had the same problem and found that Microsoft is no longer trust certificates with "sha 1" algorithm.
I solved the problem by asking my CA to replace the cerificate.
This can also happen if you have not used the switch "/d" to specify a description when signing the package. See more details under "sign Command Options" on this page:
http://msdn.microsoft.com/en-us/library/8s9b9yaz.aspx