Is there a way to use my .cer to sign ClickOnce manifest? I am investigating different deployment options and came across an article on using ClickOnce for MS VS and MS Access and it sounds like a great option because I develop in both. My first problem is that I have a certificate I have used for signing Access and VB Applications mycert.cer when I get to the part where you can sign a ClickOnce manifest in mage.exe it wants a .pfx cert. I would like, not haveing to create and maintain a second certificate. Do I have any options?
Signing using .pfx and/or .cer
- Thread starter wjburke2
- Start date
- Local time
- Yesterday, 22:30
- Joined
- Feb 28, 2001
- Messages
- 29,791
Seems to me that one of the SSL tools might do the conversion for you. I don't have links handy, but you could try looking up "SSL" and more specifically, PKCS standards (usually written as PKCS #n, where n = 1 to a number in the teens.)
Next trick would be accessing those tools. Windows has a security API that allows you to use SSL tools which might possibly include certificate stuff. Search this forum for articles on encryption. Limit the search to the last 12 months. You will find some notes (or at least a few leads) about the API in those articles.
Next trick would be accessing those tools. Windows has a security API that allows you to use SSL tools which might possibly include certificate stuff. Search this forum for articles on encryption. Limit the search to the last 12 months. You will find some notes (or at least a few leads) about the API in those articles.
Thanks doc, it would be nice to use one or the other. Can I sign a MS A2010 app with a pfx? I have found some tools that will convert the cer to a pfx and pfx to cer. Is there a way to include the certs with the install? Networking installs this app are not to happy because of the extra steps and have held up the last revision for 6 mo. because they are having a hard time getting it installed. I need a simple solution that will allow them to install a signed application, a desktop shortcut, and all the certs in a place where the user will be able to run it. I am desperately looking for a way to get this remedied.
A Security Certificate can only be used to sign code if it is stored with the Private Key. The Public Key in the certificate is used to authenticate the signature so this is what is distributed.
A pfx file contains the password protected private key but a cer file only contains the public key. A cer can be exported from a pfx but a pfx cannot be generated from a cer because the private key is not present in the cer file.
The private key for a self signed certificate is generated on the computer where the cer is created but is not exportable. Consequently these certificates can only be used to sign at the computer where they are generated.
Since the pfx contains the private key it is transportable and can be installed onto any computer where it is required to sign code.
There is only one place where certificates can be installed on a PC. The Windows Protected Store. There are a number of stores within this area for different trust authorities. They can be viewed under Internet Options > Content > Certificates. (Although found under Internet Options this is the store for all certificates including those for signing applications.)
Each user's profile has a store and there is another for the machine. Only Administrators can change the machine store. A certificate can be installed by the user in their profile. However an application cannot silently install a certificate. Otherwise what would be the point of having it?
To be recognised as a Trusted Publisher the certificate must have an authentication path to a Trusted Root Certification Authority within the environment where it is being used. Public certificates use the authentication path as shown in the certificate and can be traced back through the authorites listed in the store. These paths are installed as part of Windows.
Consequently a self signed certificate must be installed as a Trusted Root Certification Authority because simply installing it as a Trusted Publisher is not valid since the Certification Path is not authenticated. Windows will protest loudly when you install it as a Trusted Root Certificate. Never ever install a certificate you do not totally trust.
Once installed as a Trusted Root Authority, on the first run of an application signed with that certificate, the user is presented with a choice to Trust all from Publisher. Making this selection avoids the popup for all applications signed with that certificate.
This step can be avoided by also installing the certificate as a Trusted Publisher.
To avoid the user having to install the certificate it can instead be imported into the Domain Group Policies where it will automatically be installed on every computer as a Trusted Root Authority.
On the server:
Administrative Tools > Domain Security> Public Key Policies > Trusted Root Certification Authorities > (Right Click) Import ... and follow the dialog.
Unfortunately, being tied to the machine where it is generated, a new self signed certificate has to be generated when you move machines so the developer and users eventually will end up with a lot of them to maintain.
A better arrangement is to use an authenticated certificate which has the ability to be installed on any computer from the pfx file. However it is not necessary to obtain a certificate from a public authority to work within a local environment such as a domain.
Authenticate certificates can be generated by a Domain Controller running the Certification Authority Service. This service generates a pfx file in response to a request from a user. However, setting it up is fairly involved. When you install it, be sure to include the web service component which is used to apply for and distribute the pfx certificates.
Machines on the domain are aware of this authority and automatically install it as a Trusted Root Certification Authority. Any certificates issued by this authority are then available to be set as Trusted Publishers.
To completely eliminate the security question, either self signed or authenticated certificates can be added to the Software Restriction Policies.
Software Restriction Policies > Additional Rules > (Right Click) New Certificate Rule. Browse to certificate and set the Security Level to Unrestricted. This uses Group Policy to install the certificate to the client machine's Trusted Publisher Certificate Store.
A pfx file contains the password protected private key but a cer file only contains the public key. A cer can be exported from a pfx but a pfx cannot be generated from a cer because the private key is not present in the cer file.
The private key for a self signed certificate is generated on the computer where the cer is created but is not exportable. Consequently these certificates can only be used to sign at the computer where they are generated.
Since the pfx contains the private key it is transportable and can be installed onto any computer where it is required to sign code.
There is only one place where certificates can be installed on a PC. The Windows Protected Store. There are a number of stores within this area for different trust authorities. They can be viewed under Internet Options > Content > Certificates. (Although found under Internet Options this is the store for all certificates including those for signing applications.)
Each user's profile has a store and there is another for the machine. Only Administrators can change the machine store. A certificate can be installed by the user in their profile. However an application cannot silently install a certificate. Otherwise what would be the point of having it?
To be recognised as a Trusted Publisher the certificate must have an authentication path to a Trusted Root Certification Authority within the environment where it is being used. Public certificates use the authentication path as shown in the certificate and can be traced back through the authorites listed in the store. These paths are installed as part of Windows.
Consequently a self signed certificate must be installed as a Trusted Root Certification Authority because simply installing it as a Trusted Publisher is not valid since the Certification Path is not authenticated. Windows will protest loudly when you install it as a Trusted Root Certificate. Never ever install a certificate you do not totally trust.
Once installed as a Trusted Root Authority, on the first run of an application signed with that certificate, the user is presented with a choice to Trust all from Publisher. Making this selection avoids the popup for all applications signed with that certificate.
This step can be avoided by also installing the certificate as a Trusted Publisher.
To avoid the user having to install the certificate it can instead be imported into the Domain Group Policies where it will automatically be installed on every computer as a Trusted Root Authority.
On the server:
Administrative Tools > Domain Security> Public Key Policies > Trusted Root Certification Authorities > (Right Click) Import ... and follow the dialog.
Unfortunately, being tied to the machine where it is generated, a new self signed certificate has to be generated when you move machines so the developer and users eventually will end up with a lot of them to maintain.
A better arrangement is to use an authenticated certificate which has the ability to be installed on any computer from the pfx file. However it is not necessary to obtain a certificate from a public authority to work within a local environment such as a domain.
Authenticate certificates can be generated by a Domain Controller running the Certification Authority Service. This service generates a pfx file in response to a request from a user. However, setting it up is fairly involved. When you install it, be sure to include the web service component which is used to apply for and distribute the pfx certificates.
Machines on the domain are aware of this authority and automatically install it as a Trusted Root Certification Authority. Any certificates issued by this authority are then available to be set as Trusted Publishers.
To completely eliminate the security question, either self signed or authenticated certificates can be added to the Software Restriction Policies.
Software Restriction Policies > Additional Rules > (Right Click) New Certificate Rule. Browse to certificate and set the Security Level to Unrestricted. This uses Group Policy to install the certificate to the client machine's Trusted Publisher Certificate Store.
Galaxiom, you are quite knowledgeable and a quick read, kind of suggests that a application can and should be signed with a pfx. I will need to research how to do this.
One more question, but first let me explain. We are a small company developing internal apps. We have about 6-8 apps installed on around 12 computers. The users here should be able to trust anything the programming dept. puts out. I created one cert that is distributed manually. To do this I created a SelfCert, exported it and have been manually installing it to computers in the Trusted Root Authority for a couple of years. It has worked well up to this point. The Selfcert will expire on 4/22/2011. I have found a program that will allow altering a cert expire date but have not tried it. That way I keep the same cert (key) and dont have to resign every app. I have need of a way to push out the new cert when the time comes. The network dept. does not seem interested in the certificate server idea. Networking may not agree but it could be put on every computer. What is the best straegy to rollout certificates in our enviroment? What about altering the expire date?
One more question, but first let me explain. We are a small company developing internal apps. We have about 6-8 apps installed on around 12 computers. The users here should be able to trust anything the programming dept. puts out. I created one cert that is distributed manually. To do this I created a SelfCert, exported it and have been manually installing it to computers in the Trusted Root Authority for a couple of years. It has worked well up to this point. The Selfcert will expire on 4/22/2011. I have found a program that will allow altering a cert expire date but have not tried it. That way I keep the same cert (key) and dont have to resign every app. I have need of a way to push out the new cert when the time comes. The network dept. does not seem interested in the certificate server idea. Networking may not agree but it could be put on every computer. What is the best straegy to rollout certificates in our enviroment? What about altering the expire date?
Last edited:
It took quite a bit of research to put it all together. There is plenty about selfcert but nowhere puts the whole process together. The trick with the Certification Authority is even knowing what to search for. There is also a lot of confusion about certificate security out there.
In Windows itself the signing is not so much done by a pfx per se but by the private key imported into the Windows Secure Store from the pfx (or the one generated by selfcert.exe).
Other applications could extract the key directly from the pfx. They will ask you for the private key password during that process.
It is quite easy to alter the expiry date on a cer certificate.
No need for special software. Just use a Hex Editor. I use XVI32.
http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm
Between the Issued To and Issued By strings there are two number strings. The first is the issue date and the second the expiry.
They are Universal Time in the format:
yymmddhhnnssZ
However I found that Windows is not so easily fooled. The edited certificate will not import to the Trusted Root Authority store. Left to choose the store automatically it will install to the Other People store.
More work for you, none for them, which is no doubt their motivation for that decision.
However they can easily push out the self-signed certificate through group policy. Just feed in the self-signed certificate to both Trusted Root Authority and the Software Restriction policies as I explained previously. This will set it at the machine level on each client PC.
Unfortunately it seems the only other alternative is to install the certificate manually. I didn't persue trying to manually install one for the whole machine because I decided to go for the group policy install. I had a quick look but it appears that it has to be installed for each user.
I did come across a thread suggesting that certutil.exe could be used but I concluded that they were barking up the wrong tree as this is a command line manager for the CA on the server. None of the posters reported they has succeeded in using it anyway.
The Certification Authority can reissue can reissue an expired certificate. The life of the certificate can also be controlled. It defaults to one year but if it is to be changed it must be set in the ini file BEFORE the installation of the Authority. (These are the kinds of things one discovers later.)
Last edited:
This is a great reference to PFX vs CER thanks Galaxiom. My original question was about using my cer to sign ClickOnce deployment packages with Access. I finial finished my testing and found that you can use the same cer(tificate) you sign your application with to sign ClickOnce packages.
The problem I ran into was that you need to have an .exe file as the entry point to your package, ACCDB, MCCDR. MDB, MDE. will not work. So with that said ClickOnce did not work as I hoped for Access deployment.
I did find a post by HiTeckCoach with several deployment strategies that might give the results I wanted from ClickOnce. Ease of deployment and auto versioning.
Splitting your Access database into application and data
The problem I ran into was that you need to have an .exe file as the entry point to your package, ACCDB, MCCDR. MDB, MDE. will not work. So with that said ClickOnce did not work as I hoped for Access deployment.
I did find a post by HiTeckCoach with several deployment strategies that might give the results I wanted from ClickOnce. Ease of deployment and auto versioning.
Splitting your Access database into application and data
Last edited:
Mainly for those who come later and don't read the rest of the thread closely enough, I would just like to end by emphasising that the signing is not actually done by the cer but rather its corresponding private key in the Windows Protected Store.
This private key is generated by selfcert.exe but is not exportable.
Although the cer is exportable it only contains the public key used to verify the signature. The cer won't be able to sign documents when installed onto another computer.
Similar threads
