How can I reimport an SSL certificate in place of an expiring certificate in Azure Key Vault? I can't find the relevant API in the Key Vault docs (except for the original Import API).
As far as I know, If you want to reimport a new version SSL certificate in place of an expiring certificate in Azure Key Vault. You can directly import a new certificate to your Azure key vault. Once the import is final, subsequent operations will use the new policy (new versions). Refer to Import a certificate. You could also get more details from this blog.
Also, you can import a new version certificate from your Key Vault---Certificates---the old certificate---New Version---Import, on the Azure Portal.
Related
I have a windows service and part of business logic it generates a desktop file setup. Now, I want to code sign that desktop file setup Programmatically so that Windows will not warn the end user about an application from an "unknown publisher".
I also know its very straight forward process as I can do it by Microsoft signtool by taking certificate from local system and also can use Azure signtool by taking certificate from azure Key Vault for sign setup.
now, I have following doubts:
Now my problem is certificate security as windows service installed on client system and signing process will go on client system so, Its possible to misuse certificate by anyone.
currently using AzureSigntool which takes certificate from azure Key Vault directly but we doing it programmatically so we need to pass some sensitive info. like client Id, key vault Url, and secret Key with windows service code to access certificate during signing process. another point is that we doing signing by AzureSigntool on client system. does anyone can make forgery of my certificate from Azuresigntool during signing process?
If do not hesitate to suggest any other best possible approach also.
In the scenario for this question I am using a library that takes a certificate path as a parameter.
Does that mean that it is not possible for me to store my certificate in Key Vault?
Does that mean that it is not possible for me to store my certificate in Key Vault?
It is possible, but you have to give it a Name (key) to access it.
When you add/import x.509 certificates to Azure Key Vault Certificates, you give it a name (which acts as a unique key for that certificate), and you access that certificate by that name.
More info here: https://blogs.technet.microsoft.com/kv/2016/09/26/get-started-with-azure-key-vault-certificates/
Now, with regards to your other question, I am assuming you are wondering how to access a certificate from an Azure function. In your other question, you have this:
ApiSettings["SigningCertPath"]
And you indicated, you are using a (3rd party) library which picks the signing certificate path, and presumably loads that certificate. I do not know how your (3rd party) library works, or if it even works with Azure Key Vault. But it appears your library is loading the cert from a file. You did not mention if you still would like to do it that way.
But as alternative, you can load/import your certificate into your Function App (Platform features > SSL). Besides taht, you also need to add this entry to the Application Settings (on Azure portal): key WEBSITE_LOAD_CERTIFICATES and the value of *. This loads all certificates in your SSL bindings and into your Function App's certificate store. Then your function can read/get the certificate as you would get it from a local certificate store.
You can do the above instead of storing your certs in Key Vault. But you can also have all your other certs in Key Vault and only store the client certificate you need to access Key Vault from within your function.
TL;DR version: Is there any way to pass a Server certificate to an iOS client that doesn't involve also passing along the Server's private key?
I have written an iOS client app that communicates with my macOS server app (so I have control over both ends). I have implemented certificate pinning using a self-signed certificate to make things more secure. To accomplish this during development, I hardcoded the Server cert into the iOS client app and told the client to only connect to a server that gives you that exact cert during the TLS handshake. Everything is working great.
However in the real world I am selling this system as a set (1 Server, multiple clients to each customer), so I cannot hardcode a Server cert into the iOS client. My plan is to instead deliver the Server cert out of band (via email) to the iOS client like mentioned here: Making Certificates and Keys Available To Your App:
Apps can only access keychain items in their own keychain access groups.
To use digital identities in your own apps, you will need to write code to import them. This typically means reading in a PKCS#12-formatted blob and then importing the contents of the blob into the app's keychain using the function SecPKCS12Import
One way to provision an identity is via email. When you provision a device, send the associated user an email with their client identity attached as a PKCS#12 file.
My problem is that a .p12 file contains the certificate and the private key of the server - this seems very wrong to pass the private key along as well.
Is there any other way to pass the Server certificate to the iOS client that doesn't involve also passing along the Server's private key?
Thanks!!!
I was overthinking things here, the solution is actually pretty simple.
I just needed to email the Server's public certificate out of band to the client device with a custom extension like cert.myCustomExt1234. This is because the .crt extension is already claimed by iOS so you have to register your app to handle custom extensions (see apple docs here). Then in my app I can do all the logic of cert pinning using that out of band delivered Server public cert.
The key was changing the file extension to something not already claimed by iOS.
We are using AWS iOS SDK for an IoT project in our company. It is a simple application for now. User logs in to our system and tries to connect to the AWS IoT service.
https://github.com/awslabs/aws-sdk-ios-samples/tree/master/IoT-Sample/Swift/IoTSampleSwift
In the sample project above, application generates its own certificate and key pair using AWSIoT SDK. However, in our case, we don't want to generate certificates like this.
We created a Lambda Function on the server side to generate certificates for our users. iOS application requests certificate and as a response server sends a key pair, certificatePem, certificateId and certificate Arn. All of the components are created by AWSIoT SDK, if we use AWSIoTManager.defaultManager(). createKeysAndCertificateFromCsr method.
In this case, we need to import our user identity to the iOS keychain. AWS SDK has another method to handle this problem:
AWSIoTManager.importIdentityFromPKCS12Data method
We need to convert the server response to PKCS12Data to use the generated certificate. How can we do this?
Thanks in advance.
If you've got the key pair, the certificate PEM, certificate ID, and the certificate ARN, you can use the AWS Mobile SDK for iOS's IoT classes as a reference while implementing code for importing these into the keychain. The AWSIoTKeychain class contains methods for importing keys, and the AWSIoTManager -createKeysAndCertificateFromCsr: method imports the certificate into the keychain. Let us know if that information helps, and thanks for using AWS IoT.
I've been handed an iOS app codebase, which I'd like to distribute via the existing Enterprise certificate used by the prior developer.
After importing the provided .mobileprovision file, I'm (not unsurprisingly) getting the "Valid signing identity not found" error. Specifically when building:
The identity '[name]' doesn't match any valid, non-expired certificate/private key pair in your keychains
I was given the original CertificateSigningRequest.certSigningRequest file, a .p12 file, and the .cer file. I was not given the password to the .p12 file.
Is it possible to rebuild what I need from the CertificateSigningRequest.certSigningRequest without the .p12 file's password? I can likely get the .p12 password, but not in a timely manner.
Thanks!
I recognize that you've solved your issue by getting the password for the .p12 file, but I thought I'd shine a little light on what lives in each of those files you mentioned for the benefit of anyone running across the question in the future.
To answer the main question in this question: Can I rebuild what I need from the CertificateSigningRequest.certSigningRequest file?
Regrettably the answer is a very solid 'No'. The root cause of this is the very heart of Public Key Infrastructure (PKI), a set of management technologies, people, and practices dealing with the creation, verification, use, and revocation of digital certificates. Central to PKI is the notion of a public-private key pair. The 'Public' key is the one you share widely, anyone may have a copy of it and anyone wishing to validate messages signed by a digital certificate will require access to this key. The 'Private' key is the linked key that only you (or more accurately, your machine) knows and uses when signing messages. It is this signature that is verified via use of the 'Public' key that is shared widely authenticating that the message is in fact authentic.
When we are constructing development or distribution certificates, we are inherently asking Keychain Access, openssl, or your preferred SSL toolchain to create a public-private key pair. The public key goes into the CertificateSigningRequest file along with the other 'Subject' fields like name and email address and we ship this file off to Apple. That file primarily tells Apple what Public Key they can use to validate your app signature -- it does not give them a copy of your Private Key after all, if others had your private key they'd be able to codesign as you effectively destroying the notion of accountability on the iOS platform (ex. This App's signature checks out as valid, but I still don't know if it was actually signed by a developer I trust...). At no point in time, is your Private Key transmitted to Apple or the Developer Portal; it resides quite happily in your Keychain until such a time as 1) The certificate expires, 2) you actively revoke the certificate from the Developer Portal, or 3) you accidentally (or intentionally) delete the keypair from Keychain.
So what lives in each of these files?
CertificateSigningRequest.certSigningRequest - This contains a copy of the Public Key from the Public-Private keypair you generated locally, plus some additional required subject information required by the Certificate Signing Request format. Apple disregards this additional information and uses the name and email address they have on file for your Developer Account when constructing your certificate.
.p12 - This is a PKCS#12 formatted file containing a copy of the Apple-issued Certificate (which itself contains the Public Key) and a copy of the linked Private Key. This data is encrypted to prevent unauthenticated access and thus requires a password to decrypt.
.cer - This is the Apple-issued Certificate that contains the Public key portion of the key pair. This certificate is used by Apple to validate that Apps you submit are not tampered with while in transit to the App Store review team:
You sign your app using the Private key that only you know and upload the signed binary to Apple.
Apple then validate the signature using the public key that you've already shared with them.
If the math works out, then the App hasn't been tampered with and you are good to go.
If the math doesn't work out, either the app was tampered with, or (much more likely) the certificate was revoked or regenerated and the app was signed with an old or incorrect key pair.
As you can see, the only places the Private Key resides is in the original developer's keychain as well as the encrypted .p12 file. Consistent with both your comment and flup's comment, you either have to get the password to that .p12 file or look into breaking through the encryption.
Regardless, good to hear that you were able to get the password from the original developer. Let me know if you have any followup questions.