I am trying to sign my small application, following this tutorial:
In the tutorial they did not ask me to purchase Microsoft Authenticode Certificates
I need to Removes "Unknown Publisher" security warnings; after I signmy msi and exe files I still have "Unknown Publisher"
Can I sign my msi or exe without purchasing Microsoft Authenticode Certificates?
I know that I can sign Java, Authenticode, and AIR apps free: https://www.globalsign.com/en/code-signing/code-signing-tool/
No you can't remove "Unknown Publisher" security warnings without purchasing a code signing certificate.
The tutorial link describes how to create a test certificate. Quoting the first paragraph "If you use a test (self-created) certificate, the installation dialogs will display an "Unknown publisher" message."
When you purchase a code signing certificate, the certifying authority takes certain steps to verify your identity. If those steps are passed, the certifying authority issues you a certificate signed by their private key. The private key is kept secret. When you install code signed software, the operating system extracts the code signature from the software and validates it against the public key provided by the certifying authority. This is a simplification, the actual check involves a chain of certificates. But the key point is: if you use a self signed test certificate, the operating system has no knowledge of the public key of the self signed test certificate so cannot validate against it.
Related
Alert: this question is not for developers using Xcode, but for developers using "Codename One" to generate Apple certificates. If you don't know what I'm asking about, read here
I received an e-mail with subject "Action Needed: iOS Distribution Certificate Expires in 30 Days". Its body:
[...] Your iOS Distribution Certificate will no longer be valid in 30 days.
To generate a new certificate, sign in and visit Certificates,
Identifiers & Profiles.
Certificate: iOS Distribution
Team ID: xxxxxxxxxx
[...]
What have I to do with "Codename One" to renew this certificate? Have I to remove all generated iOS certificates (including Push certificates) and regenerate them? Thank you
You just need to re-run the certificate wizard and revoke the existing certificate. It will then generate new certificates for you that you can use when you resubmit your app.
Notice that this won't impact the app that's already in the store as Apple re-signs the apps when placing them in the store.
We wish to automate the process of applying a S/MIME certificate to Outlook so that it can be used for Signing and Encrypting of email. We want to be able to programmatically set security setting preferences for: the signing & encryption certificate and their corresponding algorithms.
Can we make use of Outlook MAPI or the Graph API for this purpose? Which call / field (group) should we use? Our preference is to use a C/C++ API.
For anyone trying to do the same, the following script is great (or a great place to start) for setting an S/MIME certificate to Outlook including the required settings.
https://github.com/glueckkanja-pki/PKI-Configuration-Tools/blob/master/ActivateSignatures.ps1
The scripts edits the registry entry which contains the Outlook security settings. You can run the Powershell script using 'system("start [...]")' or 'CreateProcess' for example.
To answer the subquestions: I have not found a way to do this through either Outlook MAPI nor Graph API. The registry entry is: HKEY_CURRENT_USER\Software\Microsoft\Office\"version, 16.0 for me"\Outlook\Profiles\"Profile Name"\c02ebc5353d9cd11975200aa004ae40e
I'm having difficulties setting up ADFS with OpenID Connect on Windows Server 2016.
I've setup AD for testing and I can successfully authenticate, however the email claim is not in the id token.
Additionally I've setup an external ADFS in the Claims Provider trust. It is displayed as an option, however upon logging in I get the error:
MSIS9642: The request cannot be completed because an id token is required but the server was unable to construct an id token for the current user.
Anybody have suggestions on how to fix this?
The root cause of MSIS9642 is that the new OpenID Connect Application Group features in ADFS 2016 need to issue an access token to your application. This token must include the users identity. In order to issue the token the subsystem must understand which claim in the inbound claims is used to uniquely identify the user.
A new property called AnchorClaimType has been added to the Claim Provider Trust model.
When ADFS is first installed it registers a built in Claim Provider Trust for AD AUTHORITY and sets the value for AnchorClaimType to
foo://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname
You can see this by using the powershell command get-adfsclaimsprovidertrust.
This is why OpenID works for when authenticating against Active Directory.
When you create a new Claim Provider Trust the system does not set an AnchorClaimType. The OpenID system can't issue a token because it does not know which inbound claim constitutes the unique user identity. This is why OpenID does not work when authenticating against an external Claim Provider trust.
In order to resolve this problem you need to take a few actions:
a) Verify that you are running Windows Server 2016 RTM Unfortunately the powershell attribute to set AnchorClaimType does not exist in the CTP, and the property cannot be set using the UI.
b) Choose a claim from the inbound token that represents the users identity and identify the claim type. In our case we were federating with an Azure Active Directory and chose name, and the type is foo://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
c) Set the AnchorTypeClaim for the Claim Provider Trust to the type selected by using powershell
set-adfsclaimsprovidertrust -targetidentifier identifier -AnchorClaimType http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
(get identifier from powershell get-adfsclaimsprovidertrust)
d) Create at least one inbound rule that passes through the value for the primary input claim, in our case Name
Hope this helps
To solve the problem with the missing AnchorClaimType parameter for additional added Claim Provider Trusts (CPT) a workaround for Windows Server 2016 TP5 (until end of support) can be used.
Workaround:
If CPT is already existing, delete the CPT.
Use the powershell command Add-AdfsClaimsProviderTrust
Either parameter wise (see Technet Description)
Or using a Metadata URL + the Parameter -AnchorClaimType "yourAnchorClaimValue".
Create at least one inbound rule that passes through the value for the primary input claim
In my case the following PS command solved the problem:
[String]$ClaimProviderTrustName = "YourCPTName"
[String]$MetaDataURL = "https://..."
[String]$AnchorClaimType = "YourAnchorClaimValue"
Add-AdfsClaimsProviderTrust -Name $ClaimProviderTrustName -MetadataUrl $MetaDataURL -AnchorClaimType $AnchorClaimType
I work at Microsoft. My customer had this same error. This is how we fixed it. We used Claims x-ray. We had them do a login with an identity from Active Directory and then do a login with an identity that uses an external claims provider trust.
When we compared the Claims X-Ray output, the value for anchorclaimtype didn't look right on the claims provider trust test login. We made a change in the claims provider to issue http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress as the anchor claim type and it resolved the problem.
v-michall#microsoft.com
My team is making an existing product an OpenID Connect RP (relying party) and are using connect2id's Nimbus JOSE + JWT library. That library supports signed and encrypted JWTs, but only signed first, then encrypted. They have their reasons for not supporting encrypt-then-sign, but our concern is that some of the OPs we need to interact with may do encrypt-then-sign.
We are initially targeting Salesforce and Google. I have been unable to determine from their documentation whether, when acting as OpenID Connect Providers, Salesforce and Google use sign-then-encrypt or encrypt-then-sign.
Can anyone point me to pages where this is documented for these OPs? Or is it a non-issue because no one uses encrypt-then-sign? Thanks.
When/if encryption is used, Connect OPs will always sign and then encrypt, if they are following the specification. Section 2 of OpenID Connect Core says, "If the ID Token is encrypted, it MUST be signed then encrypted". Section 16.14, Signing and Encryption Order says the same thing in a little more detail.
I am working on an application, where I have to verify that 2 files are signed with the same certificate(with our certificate). If not, then abort the program.
I found in this question, what I should do:
Validate the certificate chain completely to ensure integrity and authenticity of the certificate
Check issuer name
Check subject name
Check key usage field.
So for step 1, I use WinVerifyTrust, then I read the propertys, and compare them with each other.
So far so good, but what if someone creates a certificate, and signs these two files with them? Then it will still work. I know, that if this certificate is not added as Trusted Publisher, then WinVerifyTrust will fail. But let's say, it is added as a Trusted Publisher. Then it works. Obviously I can't write the values like "my company name" in the code, and check if a property has this value.
So how do I check if it is really my certificate? If it is really a certificate which is "Trusted", not only made trusted by me or someone else?
Thanks in advance!
If you have access to the certificate issuer (just the public key) and you trust that public key (you have acquired it by other means ---it doesn't come with the certificate you are validating, you have it already stored locally or the like--- this is the only reason to have a certificate chain) you have only to verify that the signature is valid to ensure that tha user certificate is valid. The certificate chains are only to ensure that you have one path to ensure certificate validity up to a root certificate you trust in (normally the root certificates that come with software distributions)
subject checking (or other certificate fields) is needed only in case you have different profiles or types of accounts depending on the information stored in the certificate. What use you do on subject format or fields acompanying the certificate is up to the application. Normally, people embedd information about the user account in the certificate so you can use certificates to distribute account info.
Remember that a certificate is only a public key (and some other information for whatever purpose you want it to be used to) signed by a trusted authority (this can be an intermediate certificate or a root certificate) so, once you verify the signature, you get inmediate trust on the contents. The certificate contents cannot be changed without access to the private key of the certificate issuer (to be able to sign it again) so you can trust that data in case the signature verifies ok.
How do you test if a certificate is really yours? Of course it has to be signed by a certificate issuer (this can be you or an issuer you have trust in) and verify that the issuer is that and no other certificate. In case of a corporate application you have to check that one of the signers is a certificate authority (normally for each application or application module, one or different certificate issuers are generated, each one signing user certificates that belong to that module) if you find that issuer in the certificate chain, then you can trust the certificate for the intended use.