Exchange 2019 SSL certificate install

Emilio Valentin 0 Reputation points

I could use help installing my Exchange 2019 SSL certificate. I have worked with MS support in the past to get this installed. They have always done it through Exchange powershell. I tried creating the request through the gui interface - opened the file and copied contents of file to Godaddy ssl section to create new ssl and downloaded the exchange version. When i go to

exchange admin center - servers - certificates - create new certificate - chose the 3 little dots on the right of delete tab and chose import certificate - I point to crt file downloaded from godaddy and try to walk through the steps once i point to file its asking for a password? I would really appreciate any help on this issue. Thanks

0 comments No comments
Sign in to comment

2 answers

  1. Hin-V 15,490 Reputation points • Microsoft External Staff • Moderator

    Hi @Emilio Valentin

    I hope you're doing well today.  

    You could refer to Q&A Assist's suggestion first. Based on your scenario, the behavior you’re seeing might be related to how Exchange handles certificate imports. As far as I know, Exchange typically expects a PKCS#12 (.pfx) file, as this format contains both the certificate and its associated private key in a single protected package. When a file includes a private key, it is encrypted and therefore requires a password during the import process, which explains the issue you are encountering.  

    The .crt file you downloaded from GoDaddy only contains the public certificate, which is expected because certificate authorities do not provide the private key. The private key is generated and stored on the server when the certificate request (CSR) is created. 

    Because of this, a .crt file alone is not sufficient for direct import in scenarios where Exchange requires access to the private key. In Exchange, certificates are typically installed by completing the original certificate request rather than importing them as a new certificate. 

    If the CSR was originally generated on this Exchange server, you should complete the pending request so that the issued certificate is properly associated with the existing private key. 

    Alternatively, if you have a .pfx file that includes both the certificate and private key, you can import that file and provide the password defined during export. 

    I hope this helps.  

    Please understand that our initial reply may not always immediately resolve the issue. However, with your help and more detailed information, we can work together to find a solution. 

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.   

    1. Hin-V 15,490 Reputation points • Microsoft External Staff • Moderator

      Hi @Emilio Valentin
      I hope you are doing well.

      Have you had a chance to check the replies provided?   

      Any update would be appreciated.

      If you want any further support, let me know in the comment section. I truly hope you can find the definitive solution to your concern.

    Sign in to comment

  2. AI answer

    The .crt file from GoDaddy is a PKCS #7/PKCS #12 certificate without a private key password, but Exchange expects either:

    • A PKCS #12 file (.pfx/.p12/.cer/.crt) that includes the private key and is protected by a password, or
    • A PKCS #7 chain file (.p7b/.p7c) used to complete a pending request.

    In the EAC, the Import Exchange certificate wizard always shows a Password field because PKCS #12 files that contain a private key or chain of trust are typically password-protected. If the file does not contain the private key (for example, a plain .crt issued to complete a CSR), it cannot be imported directly as a new certificate; instead, it must be used to complete the pending request that created the CSR.

    Use one of these supported paths:

    1. Complete the pending certificate request in EAC

    If the CSR was created in Exchange (EAC or EMS), there should be a pending certificate entry:

    1. In the EAC, go to Servers > Certificates.
    2. Select the server where the request was created.
    3. Locate the certificate with Status = Pending request.
    4. Use the option to complete the request and point to the .crt (or .cer) file from GoDaddy.

    This uses the existing private key from the pending request and binds the issued certificate to it. No password is required because the private key is already on the server.

    1. Import a PFX that includes the private key

    If GoDaddy provided a PFX (or if the certificate was exported from another server with its private key):

    1. Ensure the file is a PKCS #12 (.pfx/.p12/.cer/.crt) with private key and a known password.
    2. Place it on a file share accessible via UNC, for example: \\FileServer01\Data\YourCert.pfx.
    3. In EAC: Servers > Certificates > select server > More options (…) > Import Exchange certificate.
    4. On File to import from, enter the UNC path to the PFX.
    5. In Password, enter the PFX password.
    6. On Specify the servers you want to apply this certificate to, add the Exchange server(s) and finish.

    Alternatively, use Exchange Management Shell:

    Import-ExchangeCertificate -FileData ([System.IO.File]::ReadAllBytes('\\FileServer01\Data\YourCert.pfx')) -Password (Read-Host "Enter password" -AsSecureString)

    Then assign the certificate to the required services.

    1. If only a .crt without private key is available

    If only a .crt/.cer file exists and there is no corresponding pending request in Exchange and no PFX with private key, the certificate cannot be imported as-is. The private key must be present on the server (from the original CSR) or bundled into a PFX.

    Verification

    After import, verify in EAC under Servers > Certificates that the certificate appears with Status = Valid, or run:

    Get-ExchangeCertificate | where {$_.Status -eq "Valid"} | Format-List FriendlyName,Subject,CertificateDomains,Thumbprint,NotBefore,NotAfter

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.
Sign in to answer

Your answer