We are using InfoPath 2007 forms on workstations as an input form for a medical EMR package that a developer wrote in house, the user wanted the form to look pretty and have the ability to print exactly how it was scene on the screen so this was the solution the developer came up with. The forms are part of a windows application and are opened within our application using the InfoPath 2007 viewer .Net Control.
We have been using a self signed certificate and have been inserting the certificate into the Trusted Publisher cert store on application startup so that we can update the application with a self extracting zip file, however we are tightening security on our machines at work and the practice of allowing the application to control the certificates will no longer work as they are locking down user privileges, also in my opinion this is bad practice. It has been decided to move away from this practice and want to use a certificate deployed by our intermediate Domain CA, and utilize Group Policy to deploy certificates to user machines.
I have a signed InfoPath 2007 form using a domain CA issued code signing certificate using a sha256RSA signature algorithm and a sha256 hash. The certificate contains a private key and is imported to the developer personal cert store. We create a full trust InfoPath form and sign it on the developers machine using the cert mentioned in the previous sentence. We then exported the binary .cer of the certificate and deployed this cert using Group Policy to all user machines in our organization unit into the Local Machine Trusted Publisher certificate store. To test the signature piece we click on the InfoPath .xsn file outside of the application environment to launch the form in native InfoPath 2007. If we get the error that the form cannot verify the signature we know it will not work in our application as the form cannot be displayed by the Microsoft InfoPath viewer .NET control. It is as if the InfoPath form cannot recognize the certificate installed in the cert store. I check the cert store and see the certificate, however i do not see any registry entries where i would expect them to live:
HKLM\Software\Microsoft\SystemCertificates\TrustedPublisher
I am confused why none of this is working.
Does anyone have an idea as to why the certificate is not recognized by InfoPath. Can InfoPath 2007 utilize certificates that are sha256 signed and hashed?
The issue is that prior to InfoPath 2007 Build 12.0.6735.5000 SP3 MSO (12.0.6766.5000) Certificates using SHA256 algorithms are not supported. Upgrade InfoPath to the latest build.
Related
I am having problems correctly installing the OAuth certificate required for Xero partner integration on IIS 7.5 on Windows Server 2008 R2. There used to be guidance from Xero on this at http://developer.xero.com/documentation/advanced-docs/using-partner-applications-with-iis/ but the page just 404s now.
I've installed the certificate to the Trusted Root Certifications Store as per the prior Xero advice, and my code can retrieve the certificate (using its serial number); but when I try to access the private key, I get a CryptographicException: Keyset does not exist error, which other SO posts suggest is a permissions error (my application runs under a dedicated service account), but all those posts assume the certificate is installed in the personal certificate store - the TRC store does not give me the option of granting permissions to the service accounts or any other account.
I think that page used to give information about installing an Entrust client certificate as partner applications in the past needed to use one.
You don't need to use a client certificate these days and partners should instead direct their traffic to "https://api.xero.com" instead of "https://api-partner.network.xero.com".
You also don't need to install your oAuth certificate as that certificate is used only for signing your requests.
I know that Microsoft Certificate store contains certificates with their corresponding private key.
Now when using Microsoft certificate store, do we have to create it ? If yes then how ? or we get it by default with windows, then where it is located in windows 7 ?
If possible, please give an example of using MS certificate Store to display all its contents.
If you're asking how to manage certs in Windows, type certmgr.msc into search and it will bring up the manager utility.
It is default snap-in. Click on Start Ord, type certmgr.msc. If you need a cert it will import here automatically when cert is activated. This can happen a few ways, installing an application, logon script if in domain, etc. The certification is made by the developers when creating an application or portal.
I'm adding support for JWT tokens in my Web Application, and I have an X509 certificate which it needs for signing those tokens.
I have rejected the idea of using the same certificate we use for HTTPs (see Can I use the Private Key Certificate of Web App to sign JWT?).
I think a self signed certificate should do the trick, in fact I can't see any advantages of a web of trust in this scenario (that doesn't mean there aren't any, I just can't think of any).
The web application runs on a farm of web servers. My current plan is to generate a self signed cert and put the X509 certificate into the certificate store in Windows on each machine. Our IT department are checking, but they think they can roll that out to all the Web Servers in the farm using Group Policy. So this seems like a feasible plan.
The certificate store in windows looks pretty confusing to me. I think there are two options:
1) Put it in "My" store for the user under which the IIS App pool run. There are many app pools, so potentially the certificate will be in many stores.
2) Put it under the LocalMachine store, and then grant explicit access to the specific certificate for the IIS user(s).
3) Something else I can't think of.
Is there a "correct" place for these type of certs, and if so where is it?
The usual CertificateStore for signing certificates is the My store. I normally place them in LocalMachine location, but it is probably safer to put them in the certificate store for the Application Pool identity itself.
I would then give the Application Pool read-only access to this certificate only (right click certificate, then 'All Tasks' > 'Manage Private Keys', then add your Application Pool identity and give 'Read' permissions only.
I have created a ClickOnce for a simple .net console app in vs2012.
I have set the Publisher Name in the Publish --> Options --> Description --> Publisher Name.
However, when I run the setup.exe I still see Publisher: Unknown Publisher.
Why is it not picking up the Publisher Name that I have set?
You have to sign your application with a code-signing certificate to ensure that only your company is submitting data to Microsoft, and this will add a layer of security that goes beyond the traditional user name and password.
Refer these links below:
remove smartscreen filter.
msdn article
First, you must always sign the ClickOnce deployment and application manifests with a publisher certificate. Next, the certificate used to sign a ClickOnce application must be configured in the Trusted Publishers certificate store on the user's machine. And finally, the certificate authority that issued the certificate must be configured in the Trusted Root Certificate Authority certificate store on the user's machine. I'll peel back the layers of each of these three pieces in turn.
Looking for some advice about the use of client certs to retro-fit access control to an existing app.
Our company has an existing intranet app (classic ASP/IIS) which we licence to others. Up till now it's been hosted within each organisation that used it and the security consisted of "if you're able to access the intranet you're able the access the application".
I'm now looking for a way to host this app externally so that other organisations who don't wish to host it themselves can use it (each new client would have their own installation).
All user in the new organisation would have a client cert so what I'd like to do is use the 'Require Client Certificate' stuff in IIS. It allows you to say "if Organisation=BigClientX then pretend they're local userY".
What I would prefer is something that says "if Organisation=BigClientX then let them access resources in virtualdirectoryZ otherwise ignore them".
I would be very happy to buy an addon (perhaps an ISAPI filter ?) which would do this for me if that was the best approach. Any advice / war stories would be welcomed.
You likely want to do this. client certs are really intended for a second factor of authentication, but not the primary source. To say it differently, you still need to configure your app for basic or forms authentication.
The technology behind public/private keys is rock solid. However, you need a very mature IT organization who is dealing with certificate lifecycle management. If you do not have this, you will get untold failure scenarios because the certificate was expired, wasn't copied to the new computer, etc.
This is especially true in your scenario where your application is internet facing (in thee 'hosted' scenario) - you have little control about the issuance of the certificates to your users.
I've done something similar...
Generate the certificates internally from your org's domain controller. Export them both as PFX format for distribution, and CER format for you to import in IIS.
Distribute the PFX format exports along with the CA certificate for your DC, so your customers machines will "trust" your CA.
Now in the app properties IIS, go to the Directory Security tab, and under "Secure Communications" click "Edit". In there, click "Accept client certificates", "Enable Client Certificate Mapping", then "Edit".
Under the 1-to-1 tab, click "Add" and import the CER file. Enter the account you'd like to map this certificate to.
As for the "let them access resources" I'd advise doing that by the user account they're mapped through - that is, you can provide access to resources based on that account either through NTFS permissions, or through code by identifying the security context of the logged-in user.