We are trying to setup azure account in octopus with the auto generated cer file, this is not valid cer according to azure so it has to be converted to pfx, after conversion i can successfully upload certificate to azure (mind the password is a must there otherwise it will not upload) I get “ForbiddenError: The server failed to authenticate the request. Verify that the certificate is valid and is associated with this subscription.”
Any ideas as to what might be the problem?
octopus ver 3.3.15 on windows server
Thanks for getting in touch.
You should not need to convert the .cer file to .pfx (as we only need to upload the public key portion (.cer) of the certificate to the Azure portal). We tested again this morning and were able to upload the generated .cer file to the Azure Management Certificates area, as listed here.
Can you confirm you are using the old Azure portal and uploading the .cer file to the Settings > Management Certificates area of Azure?
If Azure is saying it’s not a valid cer file, could you also please double-check the subscription ID is correct and that no bad characters were accidentally copied/pasted into this subscription ID field?
Let me know how you go.
Thank you for getting back to us.
From what I could figure out its the new azure portal that is a problem as they no longer support management certs but user/pass. Yet I don’t seem to find a way in octopus to achieve that. Is the octopus able to connect to old portal only at the moment?
Octopus can connect to both and new and old APIs. The method of authentication (Management Certificate vs Service Principal Account) depends on what you’re trying to deploy.
Azure Management Certificate Accounts are only able to interact with the legacy Azure interface known as the “Azure Service Management API”, which is used when Octopus deploys Cloud Services and Azure Web Apps. To interact with Azure Resource Manager (ARM), like when Octopus deploys a Resource Group Template, you must use an Azure Service Principal Account.
The “Authentication Method” section of this documentation explains the reasons why this is necessary: “The divide in authentication-methods in Octopus reflects the divide within Azure itself”
Hope this helps.
Yes we finally got it to work, its a headache with Microsoft as some of our script use both cmd-lets for clasic and new portal so we have to brake them apart depending of what we are interacting with. Anyway thanks for your help.