I have an app service certificate and noticed that some macOS and iOS browsers are not trusting it anymore (as per the advisory Microsoft sent on April). I proceeded to rekey and sync the certificate. Rekey was successful, I can see a new certificate thumbprint, however when I click "Sync" button, I still see "Linked private certificates are out of sync" message, and the linked certs have the old thumbprint. I tried deleting the certificate from the app service and reimporting it from keyvault manually with no luck. I have waited about 10 hours so far, and heard that there was a 48 hour wait time for the automated job to sync the certs. Just wondering why the manual sync is not working and how I can force it.
Syncing of certificates after rekeying is automatic for Azure. However, the manual process takes a minimum of 24hrs before syncing. Furthermore, when you try to delete a certificate, you receive the following error message:
"Unable to delete the certificate because it is currently being used in a TLS/SSL binding. The TLS binding must be removed before you can delete the certificate."
Cause
This problem might occur if another app uses the certificate.
Solution
Remove the TLS binding for that certificate from the apps. Then try to delete the certificate. If you still can't delete the certificate, clear the internet browser cache and reopen the Azure portal in a new browser window. Then try to delete the certificate.
You can read this Microsoft Doc
Related
I had a working solution that has been in service for 1+ years. On 4/8/2022, the certificate expired, and I got a new certificate from my Service Desk group. I re-uploaded the certificate to my Azure App Service, and then realized I needed to re-deploy the code with the new Thumbprint. I am uploading to the TLS/SSL settings Private Key Certificates (.pfx).
I re-deployed along with some debugging log lines, and it seems that StoreName.My + StoreLocation.CurrentUser has 0 certificates currently in the store. This is pre any thumbprint filtering.
As I said, this has been working for the last 1-2 years, but the new certificate is now causing it to fail. I attempted to look at a couple other stores, they had certificates in them, but none of them had my Thumbprint. [40 in Root,CurrentUser] [9 in My,LocalMachine].
I am using a code equivalent to the example here: https://learn.microsoft.com/en-us/azure/app-service/configure-ssl-certificate-in-code
Edit: noteworthy, this all works fine on my local computer.
Someone at my company found the following Stack Overflow post that talks about WEBSITE_LOAD_CERTIFICATES configruation being a wildcard entry.
This fixed my problem.
Certificate not found on Azure Web App
We have a worker process running in IIS (Windows Server 2019) that makes an https request to a kafka resource in AWS in the background. In order for this process to work, we have to import certificates from Amazon into the local computer cert store so that the ssl connection can be established and it will trust the certificate presented from the resource in AWS. We have imported the cert chain and gotten this to work with the following caveats:
The service account specified for the AppPool identity has to be a local admin
OR
We have to run some process, ANY process (other than w3wp.exe that's already running), as the service account.
I've dealt quite a bit with certs, permissions, etc, but what is really odd about this one is that if I open notepad, for example, as the service account, then as long as notepad is running the process works - meaning it reads the cert and is able to establish the ssl connection. If I close notepad, the process then fails, and I get the following error:
ssl://b-2.kafkamsk.abc123.c2.kafka.us-west-2.amazonaws.com:9094/bootstrap: SSL handshake failed: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed: broker certificate could not be verified, verify that ssl.ca.location is correctly configured or root CA certificates are installed (add broker's CA certificate to the Windows Root certificate store) (after 72ms in state CONNECT)
(text in the URL replaced with abc123 for obfuscation)
Note that we don't need to access the private key of the cert, we simply need to read the cert from the cert store. The CA cert has been imported into "Trusted Root Certification Authorities." The intermediate cert has been imported into "Intermediate Certification Authorities" and the leaf cert has been imported into the personal store - all of these in the Local Computer cert store. And again, it all works if we simply login and run some process as the service account, even without it being a local admin.
I've run sysinternals procmon while executing the process that fails, and see several access denied attempts on HKEY_USERS.DEFAULT\Software\Microsoft\SystemCertificates, and those do not appear if I have notepad running as the service account when attempting the process. I've given explicit permissions to the service account on those registry keys, but it has not helped.
For obvious security reasons, we don't want our service account to be a local admin on the box, and for operations/administration reasons we don't want to rely on having some other process running as this account just to make this work.
It probably works when notepad is run as its triggering the user profile to be loaded, terminating notepad causes the profile to be unloaded. If you were to set LoadUserProfile to true on the app pool it would probably work - BUT this is not a good idea.
I think the proper solution is related to the permissions for IIS AppPool\AppPoolName on the certificate itself (which boils down to a file on disk with an ACL somewhere). Grant the app pool rights via the Certificates MMC or powershell and it should work.
if you download the latest .pem file from https://curl.se/docs/caextract.html, you can specify that file in the code with:
"ssl.ca.location",caCertLocation
Event Hubs Demo from Azure here:
https://github.com/Azure/azure-event-hubs-for-kafka/blob/master/quickstart/dotnet/EventHubsForKafkaSample/Program.cs
I am creating a VPN in Azure, and created self-signed certificate in the following places:
Local Computer:
Personal/Certificates: Issued To: FQDN name is the certificate's name
Trusted Root Certification Authorities/Certificates:
manually copied from Personal
I have configured the VPN in Azure and it is downloaded and extracted and the vpn client is installed successfully, however, when I run the client I received the following error:
A certificate could not be found that can be used with this Extensible
Authentication Protocol. (Error 798)
Screenshot:
The error seems suggesting the certificate is NOT found, does the name matter?
Should I change the cert's name from Azurecert to FQDN which is the name in my local computer?
Thank you for your help in advance.
UPDATE:
I removed the existing certification in Azure's configuration and re-added back with the same FQDN name shown in local computer's certificates, I redownloaded the client, I removed the existing installed vpn client and re-installed the new one, I receive the same error message. So it seems name is not the root cause?
UPDATE2:
The procedure I've followed:
Create Self Signed Certificate with the FQDN name on local laptop;
New-SelfSignedCertificate –DnsName NV-RXIE.novantas.pri -CertStoreLocation “cert:\LocalMachine\My”
Add the self-signed certificate as a trusted certificate authority, Copy the new cert to Trusted Root Certificate Authorities
export the cert and open it, copy the cert part and paste into the
VPN setting – Root certificates, Public Certificate Data
Download the VPN client and install it on laptop, run it
Connect, failed with:
A certificate could not be found that can be used with this Extensible
Authentication Protocol. (Error 798)
When you try to connect to an Azure virtual network by using the VPN client, except for exporting the root certificate public key .cer file to Azure, each client computer that connects to a VNet using Point-to-Site must have a client certificate installed. You generate a client certificate from the self-signed root certificate and then export and install the client certificate. If the client certificate is not installed, authentication fails.
This problem occurs if the client certificate is missing from Certificates - Current User\Personal\Certificates.
You could follow this solution to fix this issue. For more information about how to install the client certificate, see Generate and export certificates for point-to-site connections.
In case anyone runs into this issue at some stage, I had installed a new root cert that worked for 2 out of 3 VPN gateways fine. The third kept giving a 798 error even though the certs were correct and in the right place.
To fix the Error 798, I did the following:
reset the gateway in Azure Portal. (support & troubleshooting on VPN gateway blade)
remove the VPN configuration from my pc (win10)
reboot pc (just to be safe)
download and reinstall the VPN client from the Azure Portal again (from Point-to-site configuration on Azure VPN gateway in question)
Once done, I could then connect without any issues. Tested on several different users.
My guess is that if you are adding / removing the Root certs it might need you to reinstall the VPN client on your computer after the gateway has the new root cert configuration.
Hope that helps.
In addition to the answer by Nancy Xiong:
If you are still having problems with this error you can try the following
Run certmgr.msc
Go to Personal->Certificates
Right-click your certificate
All Tasks->Export
Choose Yes: Export private key
Accept default options until you reach a step where you must enter a password
Enter a password, and continue until you have exported your certificate
Repeat this process if you have more than one certificate
Locate your certificates in the Windows file explorer
Right-click->Install
Select Current User for the Store Location
Accept default options, and enter the certificate password when prompted
When asked which Certificate Store to place the certificate in, select Place all certificates in the following store
Click 'Browse' and select your Personal store
This should now work.
In rare circumstances you may find that this solution will only work for a short time (usually failing the next time you reboot). In this case you may need to follow these additional steps
Boot your computer into BIOS Configuration
Disabled any settings for Intel VTX and Intel VTD
Restart your computer
Retry the steps above
In addition to the answer by Peter Morris, I have did the below mentioned steps which helped in resolving this issue.
Delete the client certificate from your PC. This can be done by searching Manage User Certificates right click on the certificate -> Delete
Now, Reinstall your certificate, Accept default options, and enter the certificate password when prompted.
When asked which Certificate Store to place the certificate in, select Place all certificates in the following store
Click 'Browse' and select your Personal store
Accept all the default options which comes next and click finish.
The above steps helped me to resolve this issue
For me, I got this error because my previous cert has expired after 1 year.
I just deleted the old cert and followed this to create a new one:
https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-certificates-point-to-site
I'm trying to remove a certificate (via the Management Portal) that is due to expire on 16/07/2014 days and I'm getting this error:
The certificate I'm trying to delete was automatically generated 'CN=Windows Azure Tools' and was used for Remote Access.
I also tried to configure the cloud services to use new certificates, but still no success.
Looked at Fiddlers log and indeed there in an internal server error:
My questions are:
Is there any way I can delete this certificate?
If I can't delete it, what happens when it expires?
What I really want to avoid is to have to redeploy the production services because of this certificate.
Florin, you cannot delete a certificate in production use, but you have two options for this issue:
The easiest option is to just ignore it. The RDP cert is only used for password encryption and it doesn't matter if the cert is expired or not since Azure does not check the expiration date when doing the encryption/decryption.
You can upload a new certificate and then modify the RDP configuration to use that new certificate. After this you can delete the old certificate. This is essentially the same process you would use for an HTTPS certificate.
I have a cloud service SAAS application that is running on Azure using https which SSL certificate is expiring soon. I've recently obtained a new SSL certificate that I need to apply to before the expiration date.
Looking up on the web, all I found are articles about how to setup SSL certificate for Azure Cloud Service (i.e. http://www.windowsazure.com/en-us/develop/net/common-tasks/enable-ssl/) and non regarding the renewal process. At this point, I'm thinking it's the same process.
In order to avoid unnecessary issue, I'm looking for confirmation from someone else that might have already done this before and perhaps some pointers on other things that I need to be aware of.
1)You upload the certificate to the Service Certificates section on the Windows Azure Portal - just as you did originally.
2) You modify the Service Configuration file to provide the thumbprint of the new certificate instead of the old one. This causes the certificate to be deployed to each instance.
3) You do an in-place upgrade or (use a VIP Swap) which causes IIS to start using the new certificate.
First you upload the new certificate using the Management Portal - go to Certificates tab of your cloud service.
Then if you believe in in-place reconfiguration (which I don't recommend for this scenario) you can go to Configure tab, scroll down to Certificates, change the thumbprint (you can get it from the Certificates tab) and click Save. Just don't forget to update your .cscfg files so that you have the changes preserved when you redeploy.
If you don't believe in in-place reconfiguration you'll have to change your .cscfg files and deploy your service into staging with the updated .cscfg and then do VIP swap and delete the previous deployment. This is what I recommend for this scenario because should anything go wrong with in-place reconfiguration you can experience service downtime.