Which certificate to use for a simple DVA?

GW24.4; simple: one Dom, one PO, one DVA.

As KM000004429 says: "If the DVA runs on a host where also other GW agents are running, you can use, for instance, a certificate and a key files of a POA."

I use the cert. and key from the PO.

The POA log shows the DVA offline.the CLI shows the DVA is running; ss show the port (8301) is listening

openssl shows:

> echo quit | openssl s_client -connect gw2.internal:8301 -showcerts
CONNECTED(00000003)
806BDF0F9B7F0000:error:0A00010B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:355:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 323 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Even if I try to connect with a browser I get an error message ...

If I create a own cert for the dva,signed by the GW-CA I get the same errors

I assume that the setting in gwdva.dva is wrong. I use the default:

;----------------------------------------------------------------------
; SSL Context Set Option
; Enable user to disallow specific SSL protocol and to allow specific protocol version.
; For security reason, GroupWise does not support SSLv2, SSLv3, TLSv1 and TLSv1_1 by default.
; e.g. By specifying SSL_OP_NO_TLSv1_2, GroupWise will disable TLSv1_2 support.
; However, for supporting older version of client, such as Mac client, we allow
; you to overwrite the default by specifying SSL_OP_ALLOW_TLSv1 at your own discretion.
; You can specify additional options by adding the SSL key word separated
; by a comma, such as "SSL_OP_NO_TLSv1_2,SSL_OP_ALLOW_TLSv1 or SSL_OP_ALLOW_TLSv1_1".
;
;-----------------------------------------------------------------------
;--sslOption ["SSL_OP_NO_TLSv1_2,SSL_OP_ALLOW_TLSv1"]

;----------------------------------------------------------------------
; SSL Cipher Suite
;
; Enable user to specify the order and the allowed SSL cipher suites.
; Cipher list must be in OpenSSL format. For more details see the following:
; www.openssl.org/.../ciphers.html
;
; The default in 18.5 and 23.4 was "ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:!NULL:!RC4:!RC2:!kDHE:!DES:!3DES:!SHA:!SHA256:!SHA384:!MD5+HIGH:+MEDIUM:@STRENGTH"
; The new default in 24.1 is "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:
; ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305"
; WARNING: Configuring this incorrectly could cause the agents to not
; start or the clients to fail to connect. For most environments
; the built-in default will suffice.
;----------------------------------------------------------------------
;--sslciphersuite ["cipher list"]

If I disable SSL in the DVA-Object (in GWAdmin-UI) the POA shows it as running ...

Any hints?

  • 0  

    If you use the poa cert, do not forget to use the same password that you used in your admin console.

    As already posted in another thread quotes (") will help. Especially for the password.


    Use "Verified Answers" if your problem/issue has been solved!

  • 0  

     cat /opt/novell/groupwise/agents/share/gwdva.dva

    ........

    ;  Enable SSL for Https
    ;  Valid server certificate in PEM format obtained from a Certificate
    ;  Authority ( CA )
    ;----------------------------------------------------------------------
    --httpssl
    ;--sslCert /certs/server.pem
    ;--sslKey /certs/server.key
    ;--sslKeyPassword novell
    --sslCert /opt/novell/gw/certs/server.crt
    --sslKey /opt/novell/gw/certs/server.key


    Self-signed, wildcards and commercial (also SAN Certs) can be used. If the internal GroupWise certificate is used, it must be checked whether the fqdn in the CN matches hostname -f.

    If the key file of a certificate contains a password, the password must also be specified in the DVA configuration or the password must be removed from the key file beforehand. The certificate file itself must be in crt or pem form. For commercial certificates, always ensure that the certificate chain is correct.
    .

    Please read community.opentext.com/.../gwia-blocked---how-do-i-unblock

    George

    “You can't teach a person anything, you can only help them to discover it within themselves.” Galileo Galilei

  • Verified Answer

    +1  

    As mentioned by Diethmar you could use the POA certificate/key file but only when the DVA runs on the same server as otherwise the SAN information ( FQDN and IP ) do not match.

    The main TID for manual creating certificates is this one as you can specify the actual servers FQDN and IP so the SAN in the certificate is correct

    Make sure that the dva config file as Georg pointed out has quotes around the path/filename like this

    --sslCert "/opt/novell/gw/certs/server.crt"
    --sslKey "/opt/novell/gw/certs/server.key"

    If a password is set on the key file add

    --sslKeyPassword "novell"

    I wrote a lot of background info in this thread this week as well

  • 0

    I had a similar problem earlier this week. This portal.microfocus.com/.../KM000006608 helped me. I, too, had used the POA certificate for the DVA for years. I did not bother with password-protecting the new key I made for the DVA since you have to insert the password in plain text in the DVA's config file. You can see all the mistakes I made on earlier posts. One thing that surprised me was I needed a cold reboot for things to work finally. I think it is fair to assume some routine is running somewhere in the background that needs to be released that is seeking an IP when you want it to seek a FQDN. In my case I was running SLES 15.6 and perhaps did a zypper update that did not demand a reboot, and so I did not reboot. Likely if I had rebooted after the update and before tinkering with configurations I would have been less frustrated.

  • 0   in reply to 

    I hate plain text passwords somewhere. But it is simple to remove passwords from key files for these purposes:

    openssl rsa -in [original.key] -out [new.key]


    Use "Verified Answers" if your problem/issue has been solved!

  • 0   in reply to   

    Hello Diethmar,

    Passwords in keyfiles, many times in the background, there are scenarios where a password is necessary in the keyfile. An exception is e.g. the CA for the gwldap if ssl is configured.

    Greetings Georg

    “You can't teach a person anything, you can only help them to discover it within themselves.” Galileo Galilei

  • 0   in reply to   

    I know.

    But this time (dva) it is simple to solve. And for Apache, and for nginx, and ...


    Use "Verified Answers" if your problem/issue has been solved!

  • 0 in reply to   

    If you use more then one DVA on different MTA, then you have to provide the same SAN in all (DVA-) certs. Otherwise the SSL-Check in GWWEB is not successful.

    In this case you can't use the (default) MTA-Cert. Flushed

    Meanwhile I have learned that there are two different certificate lines:

    The one is the internal GW-Cert line. It is sometimes selfmanaged (otherwise via geadminutil [ca|certinst]) and invisible in GWAdminUI. This is used of internal GW communication. (POA; MTA; DOM; DVA; and so on)

    The other is visible in GWAdminUI and is used for external communication(?, at least in GWIA; maybe in in the POA if you use the IMAP/POP at the POA)

  • 0   in reply to 

    DVA is a POA thing - not MTA related.

    In the last two days we had many discussions about certs. There we have mentioned more than once that there are two kind of certs. Internal ones (starting with admin) and public ones (admin gui), which can be replaced by public certs if wished.

    Yes, these are good for your GWIA (imap, pop, smtp) and POA (even your GW clients not only imap). 


    Use "Verified Answers" if your problem/issue has been solved!