Convert a certificate to PFX (GoDaddy, unable to load private key)

Scenario

You’ve successfully received a SSL-certificate from GoDaddy or any other providers, and then tried to convert a crt/p7b certificate to PFX which has been required by Azure services (Application Gateway or App Service, for instance)

When you convert the cert by using the openssl you also get the following error:

unable to load private key
24952:error:0909006C:PEM routines:get_name:no start line:crypto\pem\pem_lib.c:745:Expecting: ANY PRIVATE KEY

Solution

You should check the .key file encoding.

Carry out the following steps: open the .key file with Visual Studio Code or Notepad++ and verify that the .key file has UTF-8 encoding. In my case, the file had UTF-8 with BOM encoding, so I saved the file with just UTF-8, and then tried the conversion again:

openssl pkcs12 -export -in cert.crt -inkey privatekey.key -out pfxname.pfx

In addition, make sure that .key file has a valid scheme:

-----BEGIN PRIVATE KEY-----
Cipher here
-----END PRIVATE KEY-----

Easy peasy, but troubleshooting could break you mind 🙂

Azure ARM | Cannot add the second NIC to Load Balancer (different availability sets)

Imagine that you need to configure Load Balancer (LB) to handle requests from outside to multiple scale sets , virtual machines or internal LB needs to be added in addition to external LBs. You configure VMs, scale sets, load balancer(s), backend pool and define load balancing rule. The following example shows an excerpt from the arm template:

 ####
"loadBalancingRules": [
                    {
                        "name": "[variables('lbInternalName')]",
                        "properties": {
                            "frontendIPConfiguration": {
                                "id": "[variables('lbInternalFrontEndId')]"
                            },
                            "backendAddressPool": {
                                "id": "[variables('lbInternalBackEndPoolId')]"
                            },
                            "protocol": "Tcp",
                            "frontendPort": 80,
                            "backendPort": 80, 
                            "enableFloatingIP": false,
                            "idleTimeoutInMinutes": 5,
                            "probe": {
                                "id": "[variables('lbInternalProbeId')]"
                            }
                        }
                    }
                ],
####

What can go wrong? Pay attention to the Load Balancer SKU.

You deployment/configuration may fail with the following errrors:

  • Network <..> associated with different availability set <…>
  • Network Interface and Load Balancer are in different availability sets

And, if you are trying to configure scale sets with multiple load balancers:

  • Different basic sku and standard sku load balancer or public Ip resources in VMSS is not allowed

So, if your goal is to associate multiple scale sets with a load balancer, the load balancer must be Standard. Only Standard LB allows you to have multiple endpoints in a backend pool. Also, make sure you are not mixing the LB SKUs. It happens often when int and ext LBs are in use.