GW2014 14.2.0 certificate change fails for agents

Hi,

I have 3 party certificate(Comodo wildcard) which I would like to add our GroupWise agents(mta, poa, gwia). I'm facing some kind of problem with private key based on what the error message say:
MTA error: SSL Configuration has been disabled because of failure in setting up SSL rc= [891D]

SSL Certificate File: I have combined server certificate with bundle which I got with the certificate.
Private key: base64 encoded, no password, PKCS8. Tried also PKCS1 format. I also tried set password.

Certificate and private key matches because those are use in other services checked with openssl modulus.

If someone can point me to the right direction I would appreciate that!

-Antti

Tags:

  • aniskanen;2474456 wrote:
    Hi,

    I have 3 party certificate(Comodo wildcard) which I would like to add our GroupWise agents(mta, poa, gwia). I'm facing some kind of problem with private key based on what the error message say:
    MTA error: SSL Configuration has been disabled because of failure in setting up SSL rc= [891D]

    SSL Certificate File: I have combined server certificate with bundle which I got with the certificate.
    Private key: base64 encoded, no password, PKCS8. Tried also PKCS1 format. I also tried set password.

    Certificate and private key matches because those are use in other services checked with openssl modulus.

    If someone can point me to the right direction I would appreciate that!

    -Antti


    hi,

    add rootca to the chain. chain from top to bottom: your cert-intermediate-rootca. save chain as crt file. also check your pc time. certs are very time sensitive. also delete the password.

    bye
  • In article <aniskanen.8bwu5z@no-mx.forums.microfocus.com>, Aniskanen
    wrote:
    > I have 3 party certificate(Comodo wildcard) which I would like to add
    > our GroupWise agents(mta, poa, gwia).
    > ...
    > SSL rc= [891D]


    I'm not sure if this is a supported combination.
    The Docs only show the patch of submitting a CSR for every host and
    nothing about using a wild card cert that is a fairly common thing.
    Now it could be an oversight, but shows we are off the documented path
    unless someone else can point us to some.

    A) Make sure it the cert file is simply named. In the past there has
    been a need for 8.3 limited names. Shouldn't be now, but one never
    knows and worth trying.
    B) Is the cert SHA-1 or SHA-256 based? I got some hits on this being
    one cause of that error code when I googled it. A way to test is to
    point some test tools at any website you have using that wildcard. The
    three I usually use are:
    https://www.ssllabs.com/ssltest/
    https://sslanalyzer.comodoca.com/
    https://ssltools.websecurity.symantec.com/checker/views/certCheck.jsp
    If they show your cert is still SHA-1 based, talk with your cert
    provider as they are usually good about reissuing the old long lived
    certs that are still SHA-1. (A friend had to do that for a couple that
    were the old 5 year certs that have a bit of life left)


    Andy of
    http://KonecnyConsulting.ca in Toronto
    Knowledge Partner
    http://forums.novell.com/member.php/75037-konecnya
    If you find a post helpful and are logged in the Web interface, please
    show your appreciation by clicking on the star below. Thanks!


  • > add rootca to the chain. chain from top to bottom: your cert-intermediate-rootca. save chain as crt file. also check your pc time. certs are very time sensitive. also delete the pass


    I have tried that cert-intermediate-rootca combination. I'll try it again. Also pc time is correct. There is currently 3 party cert installed(not wildcard) and it's working properly. No password set (also tried with password)

    Maybe there is point what Andy is saying about wildcard certs. Has anyone used wildcard certs successfully? It's shame if they don't work. Then I need to buy couple extra certificates.


    I also checked that there is no extra startup switches.

    Answers to the Andy's questions
    A) I'll try this next(I'm almost sure that I tried this already but need to be sure). I found same naming limitation mention from GroupWise 8 blog writing.
    B) Cert is SHA-256 based

    MTA starts up with ssl on if I change format to pfx. I found this from documentation: SSL Key File: Browse to and select the key file associated with the certificate. If the private key is included in the certificate file rather than in a separate key file, leave this field blank. If you type the file name, specify the full path if the file is not in the certificates folder.

    I exported pfx file from NAM(wildcard cert is working there). Pfx file contains both cert and private key. MTA diagnostics confirms that it is using pfx file but how can I be sure?
    openssl s_client -showcerts -connect my.domain.com:7180 shows only that previous certificate...

    This pfx file doesnt work on GWIA or POA. They just don't start. No error messages.

    -Antti
  • If I remember correctly, the GW agents require a password on the key file.

    --Morris



    aniskanen;2474456 wrote:
    Hi,

    I have 3 party certificate(Comodo wildcard) which I would like to add our GroupWise agents(mta, poa, gwia). I'm facing some kind of problem with private key based on what the error message say:
    MTA error: SSL Configuration has been disabled because of failure in setting up SSL rc= [891D]

    SSL Certificate File: I have combined server certificate with bundle which I got with the certificate.
    Private key: base64 encoded, no password, PKCS8. Tried also PKCS1 format. I also tried set password.

    Certificate and private key matches because those are use in other services checked with openssl modulus.

    If someone can point me to the right direction I would appreciate that!

    -Antti
  • i use a comodo multidomain wildcard cert and dont have any issues. for comodo you 2 intermediate certs. also, i dont think the default cert created by gw has a password set.
  • Thank you all for the answers. Problem solved. Bahsig said that wildcard cert will work so then I started to seek problem from some where else and found it. Turns out that we were using sles 11 sp3 without ltss. Of course we were missing come critical cert updates. Upgraded to sp4 and everything work well now.

    combined server cert bundle. No password needed for key file!

    -Antti
  • In article <aniskanen.8c7ptz@no-mx.forums.microfocus.com>, Aniskanen
    wrote:
    > Turns out that we were using sles 11 sp3 without ltss. Of
    > course we were missing come critical cert updates. Upgraded to sp4 and
    > everything work well now.
    >
    > combined server cert bundle. No password needed for key file!


    Thank you for the update. Sharing this may well help someone else along
    the way.


    Andy of
    http://KonecnyConsulting.ca in Toronto
    Knowledge Partner
    http://forums.novell.com/member.php/75037-konecnya
    If you find a post helpful and are logged in the Web interface, please
    show your appreciation by clicking on the star below. Thanks!