Mailing List Archive

Hi Jethro,

first of all: 12.5.01g is really old and is vulnerable to POODLE and a
few others. You really want to update this.

I assume you combined the intermediate cert into the regular cert file?
This will not work.

You need to use:

ssl profile www.something.com
keypair-file yourkey.key
certificate-file yourcert.crt
ca-cert-file your-cert-ca-chain.crt
enable-certificate-chaining


Cheers,
Jonas



Am Montag, den 09.11.2015, 16:05 +0000 schrieb Jethro R Binks:
> Hi,
>
> I'm banging my head against a wall here and looking for some help.
>
> One virtual service is having a cert change due to expiry, and I've got
> the .pfx as exported from Windows. I have extracted the key and cert from
> this. I have the intermediate and root certs.
>
> I can upload all, the key to the keyfile, and the host cert then the
> intermediate to the cert file using scp. Done this some number of times
> in the past routinely.
>
> I can use the show commands to view the cert chain, and see the host's
> cert plus the intermediate.
>
> However what I can't do is the actual bind of the cert into the ssl
> profile:
>
> SSH@sender(config)#ssl profile tcnemo-toclients
> SSH@sender(config-ssl-profile-tcnemo-toclients)#keypair-file tcnemo_2015.key
> SSH@sender(config-ssl-profile-tcnemo-toclients)#certificate-file tcnemo_chain_2015.crt
> SSH@sender(config-ssl-profile-tcnemo-toclients)#Error key and certificate mismatch
> Please delete the key and re-add the right key and certificate
> SSL profile : tcnemo-toclients
> Certificate file : \usb0\certstor\tcnemo_chain_2015.crt.cert
> Key file : \usb0\certstor\tcnemo_2015.key.key
>
> The only help I can get from Dr Google is the suggestion from the
> documentation that this key does not match the certificate. But both came
> from the exported PFX, and I've verified them manually in various ways.
> Now totally stuck as to what to do next (and time is ticking for the
> previous cert expiry :).
>
> Anyone any ideas?
>
> ADX 12.5.01g
>
> Jethro.
>
> . . . . . . . . . . . . . . . . . . . . . . . . .
> Jethro R Binks, Network Manager,
> Information Services Directorate, University Of Strathclyde, Glasgow, UK
>
> The University of Strathclyde is a charitable body, registered in
> Scotland, number SC015263.
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp

On Mon, 9 Nov 2015, Jonas Frey (Probe Networks) wrote:

> Hi Jethro,
>
> first of all: 12.5.01g is really old and is vulnerable to POODLE and a
> few others. You really want to update this.

Can't disagree with that! What would you currently recommend as stable?

> I assume you combined the intermediate cert into the regular cert file?
> This will not work.

That's funny, it is what I've always done, has always worked, and that's
what the documentation tells me to do in 12501 Security Guide:

"
Step 1: Import server certificate and intermediate CA certificates

...

The order is important. The server certificate should be imported before
the intermediate CA certificate.

The same file name should be used (chain2cert in this example) when
importing both the server and intermediate CA certificate."

> You need to use:
>
> ssl profile www.something.com
> keypair-file yourkey.key
> certificate-file yourcert.crt
> ca-cert-file your-cert-ca-chain.crt
> enable-certificate-chaining

As I understand it, ca-cert-file is only required for verifying the certs
of connecting clients, which I am not doing.

My process has worked fine for various other certs and CAs. This one is
different in that it is the first signed by this CA. I have also uploaded
the CA root cert for use in the ssl-proxy line. I have re-downloaded from
the CA the intermediate cert for inclusion (I had some trouble getting
that uploaded, I think perhaps a missing newline at the end was causing
the problem).

An example of a working config for us is:

ssl profile nemo-toclients
keypair-file nemo_2015.key
certificate-file nemo_chain_2015.crt
cipher-suite all-cipher-suites
enable-certificate-chaining
session-cache off

ssl profile entrust2048-server
cipher-suite all-cipher-suites
disable ssl2 ssl3
ca-cert-file entrust2048-ca.crt
session-cache off

server virtual ex2010-cas-lb ...
predictor round-robin
port ssl sticky
port ssl ssl-proxy nemo-toclients entrust2048-server
port ssl csw-policy "exch2010a"
...

where nemo_chain_2015.crt contains the server cert and the intermediate,
and entrust2048-ca.crt is the CA root which issued. The clients get the
cert + intermediates.

Replicating this for this new certificate/intermediate and CA is what is
failing for me.

Danke or the thoughts, but I'm not sure it has helped yet.

Jethro.



>
>
> Cheers,
> Jonas
>
>
>
> Am Montag, den 09.11.2015, 16:05 +0000 schrieb Jethro R Binks:
> > Hi,
> >
> > I'm banging my head against a wall here and looking for some help.
> >
> > One virtual service is having a cert change due to expiry, and I've got
> > the .pfx as exported from Windows. I have extracted the key and cert from
> > this. I have the intermediate and root certs.
> >
> > I can upload all, the key to the keyfile, and the host cert then the
> > intermediate to the cert file using scp. Done this some number of times
> > in the past routinely.
> >
> > I can use the show commands to view the cert chain, and see the host's
> > cert plus the intermediate.
> >
> > However what I can't do is the actual bind of the cert into the ssl
> > profile:
> >
> > SSH@sender(config)#ssl profile tcnemo-toclients
> > SSH@sender(config-ssl-profile-tcnemo-toclients)#keypair-file tcnemo_2015.key
> > SSH@sender(config-ssl-profile-tcnemo-toclients)#certificate-file tcnemo_chain_2015.crt
> > SSH@sender(config-ssl-profile-tcnemo-toclients)#Error key and certificate mismatch
> > Please delete the key and re-add the right key and certificate
> > SSL profile : tcnemo-toclients
> > Certificate file : \usb0\certstor\tcnemo_chain_2015.crt.cert
> > Key file : \usb0\certstor\tcnemo_2015.key.key
> >
> > The only help I can get from Dr Google is the suggestion from the
> > documentation that this key does not match the certificate. But both came
> > from the exported PFX, and I've verified them manually in various ways.
> > Now totally stuck as to what to do next (and time is ticking for the
> > previous cert expiry :).
> >
> > Anyone any ideas?
> >
> > ADX 12.5.01g
> >
> > Jethro.
> >
> > . . . . . . . . . . . . . . . . . . . . . . . . .
> > Jethro R Binks, Network Manager,
> > Information Services Directorate, University Of Strathclyde, Glasgow, UK
> >
> > The University of Strathclyde is a charitable body, registered in
> > Scotland, number SC015263.
> > _______________________________________________
> > foundry-nsp mailing list
> > foundry-nsp@puck.nether.net
> > http://puck.nether.net/mailman/listinfo/foundry-nsp
>

. . . . . . . . . . . . . . . . . . . . . . . . .
Jethro R Binks, Network Manager,
Information Services Directorate, University Of Strathclyde, Glasgow, UK

The University of Strathclyde is a charitable body, registered in
Scotland, number SC015263.
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

Hi Jethro,

using 12.5.02d here without any problems for a while. (note 12.5.02e is
available).
12.5.02x finally has TLS 1.2 and SNI, so you will want this.

As for the ca-cert-file: No, this is not for verifing the connecting
clients, it really is what the name says, this is where your CA-Cert
chain will be loaded.

Maybe your chaining has worked (for some reason) while including the
chain with your certificate for now. However i guess you now also have a
SHA256 cert and this probably is the reason this no longer works.
ca-cert-file has been there for some time and this is the recommended
method.

Also i think you are using ssl-proxy incorrect in this setup, from the
CLI:

SSH@lb-test(config-vs-www.xyz.com)#port ssl ssl-?
ssl-proxy SSL on both client-side and server-side

SSH@lb-test(config-vs-www.xyz.com)#port ssl ssl-proxy ?
ASCII string Name of the SSL profile to be associated with this
virtual port for traffic towards clients

SSH@lb-test(config-vs-www.xyz.com)#port ssl ssl-proxy testing ?
ASCII string Name of the SSL profile to be associated with this
virtual port for traffic towards real servers


So if you are using
port ssl ssl-proxy nemo-toclients entrust2048-server

then you will authenticate with "nemo-toclients" to your external
clients - which is fine. However this does not include the cert chain.
Furthermore you send the SSL requests to your internal
"entrust2048-server" only with your cert chain as the profile
"entrust2048-server" only includes the chained cert.

Please try using the ca-cert-file option. I am sure it works (atleast it
does for us :-)


Cheers,
Jonas





Am Montag, den 09.11.2015, 20:14 +0000 schrieb Jethro R Binks:
> On Mon, 9 Nov 2015, Jonas Frey (Probe Networks) wrote:
>
> > Hi Jethro,
> >
> > first of all: 12.5.01g is really old and is vulnerable to POODLE and a
> > few others. You really want to update this.
>
> Can't disagree with that! What would you currently recommend as stable?
>
> > I assume you combined the intermediate cert into the regular cert file?
> > This will not work.
>
> That's funny, it is what I've always done, has always worked, and that's
> what the documentation tells me to do in 12501 Security Guide:
>
> "
> Step 1: Import server certificate and intermediate CA certificates
>
> ...
>
> The order is important. The server certificate should be imported before
> the intermediate CA certificate.
>
> The same file name should be used (chain2cert in this example) when
> importing both the server and intermediate CA certificate."
>
> > You need to use:
> >
> > ssl profile www.something.com
> > keypair-file yourkey.key
> > certificate-file yourcert.crt
> > ca-cert-file your-cert-ca-chain.crt
> > enable-certificate-chaining
>
> As I understand it, ca-cert-file is only required for verifying the certs
> of connecting clients, which I am not doing.
>
> My process has worked fine for various other certs and CAs. This one is
> different in that it is the first signed by this CA. I have also uploaded
> the CA root cert for use in the ssl-proxy line. I have re-downloaded from
> the CA the intermediate cert for inclusion (I had some trouble getting
> that uploaded, I think perhaps a missing newline at the end was causing
> the problem).
>
> An example of a working config for us is:
>
> ssl profile nemo-toclients
> keypair-file nemo_2015.key
> certificate-file nemo_chain_2015.crt
> cipher-suite all-cipher-suites
> enable-certificate-chaining
> session-cache off
>
> ssl profile entrust2048-server
> cipher-suite all-cipher-suites
> disable ssl2 ssl3
> ca-cert-file entrust2048-ca.crt
> session-cache off
>
> server virtual ex2010-cas-lb ...
> predictor round-robin
> port ssl sticky
> port ssl ssl-proxy nemo-toclients entrust2048-server
> port ssl csw-policy "exch2010a"
> ...
>
> where nemo_chain_2015.crt contains the server cert and the intermediate,
> and entrust2048-ca.crt is the CA root which issued. The clients get the
> cert + intermediates.
>
> Replicating this for this new certificate/intermediate and CA is what is
> failing for me.
>
> Danke or the thoughts, but I'm not sure it has helped yet.
>
> Jethro.
>
>
>
> >
> >
> > Cheers,
> > Jonas
> >
> >
> >
> > Am Montag, den 09.11.2015, 16:05 +0000 schrieb Jethro R Binks:
> > > Hi,
> > >
> > > I'm banging my head against a wall here and looking for some help.
> > >
> > > One virtual service is having a cert change due to expiry, and I've got
> > > the .pfx as exported from Windows. I have extracted the key and cert from
> > > this. I have the intermediate and root certs.
> > >
> > > I can upload all, the key to the keyfile, and the host cert then the
> > > intermediate to the cert file using scp. Done this some number of times
> > > in the past routinely.
> > >
> > > I can use the show commands to view the cert chain, and see the host's
> > > cert plus the intermediate.
> > >
> > > However what I can't do is the actual bind of the cert into the ssl
> > > profile:
> > >
> > > SSH@sender(config)#ssl profile tcnemo-toclients
> > > SSH@sender(config-ssl-profile-tcnemo-toclients)#keypair-file tcnemo_2015.key
> > > SSH@sender(config-ssl-profile-tcnemo-toclients)#certificate-file tcnemo_chain_2015.crt
> > > SSH@sender(config-ssl-profile-tcnemo-toclients)#Error key and certificate mismatch
> > > Please delete the key and re-add the right key and certificate
> > > SSL profile : tcnemo-toclients
> > > Certificate file : \usb0\certstor\tcnemo_chain_2015.crt.cert
> > > Key file : \usb0\certstor\tcnemo_2015.key.key
> > >
> > > The only help I can get from Dr Google is the suggestion from the
> > > documentation that this key does not match the certificate. But both came
> > > from the exported PFX, and I've verified them manually in various ways.
> > > Now totally stuck as to what to do next (and time is ticking for the
> > > previous cert expiry :).
> > >
> > > Anyone any ideas?
> > >
> > > ADX 12.5.01g
> > >
> > > Jethro.
> > >
> > > . . . . . . . . . . . . . . . . . . . . . . . . .
> > > Jethro R Binks, Network Manager,
> > > Information Services Directorate, University Of Strathclyde, Glasgow, UK
> > >
> > > The University of Strathclyde is a charitable body, registered in
> > > Scotland, number SC015263.
> > > _______________________________________________
> > > foundry-nsp mailing list
> > > foundry-nsp@puck.nether.net
> > > http://puck.nether.net/mailman/listinfo/foundry-nsp
> >
>
> . . . . . . . . . . . . . . . . . . . . . . . . .
> Jethro R Binks, Network Manager,
> Information Services Directorate, University Of Strathclyde, Glasgow, UK
>
> The University of Strathclyde is a charitable body, registered in
> Scotland, number SC015263.
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp

On Tue, 10 Nov 2015, Jonas Frey (Probe Networks) wrote:

> using 12.5.02d here without any problems for a while. (note 12.5.02e is
> available). 12.5.02x finally has TLS 1.2 and SNI, so you will want this.

Thanks, will look through the relnotes.

> So if you are using
> port ssl ssl-proxy nemo-toclients entrust2048-server
>
> then you will authenticate with "nemo-toclients" to your external
> clients - which is fine. However this does not include the cert chain.

Well it does, according to what we've done in the past, the documentation
I read, and using openssl s_client against an existing LB virtual server I
get both the server cert and the intermediate cert. It does not send the
CA root cert, but that's what I would expect. You have that held and
trusted by the client so it can join up the dots through the chain from
the trusted root to the server (LB).

> Furthermore you send the SSL requests to your internal
> "entrust2048-server" only with your cert chain as the profile
> "entrust2048-server" only includes the chained cert.

entrust2048-server only contains the CA root cert, so the LB can verify
the identify in the cert offered by the real server. If the real server
sends the intermediate certs as well (which it does), it need contain no
more. (It probably does no harm to include the intermediates as well in
case the server only sends its own cert and not the intermediate chain).

> Please try using the ca-cert-file option. I am sure it works (atleast it
> does for us :-)

I will try it, since I have nowhere else to go! Not doubting that it
works for you, just that I know what we've done so far has worked
perfectly.

Your comment about the SHA256 could be significant, as I had considered
that might be a possibilty, but couldn't spot any relevant change in the
release notes that I looked at.

Jethro.


>
>
> Cheers,
> Jonas
>
>
>
>
>
> Am Montag, den 09.11.2015, 20:14 +0000 schrieb Jethro R Binks:
> > On Mon, 9 Nov 2015, Jonas Frey (Probe Networks) wrote:
> >
> > > Hi Jethro,
> > >
> > > first of all: 12.5.01g is really old and is vulnerable to POODLE and a
> > > few others. You really want to update this.
> >
> > Can't disagree with that! What would you currently recommend as stable?
> >
> > > I assume you combined the intermediate cert into the regular cert file?
> > > This will not work.
> >
> > That's funny, it is what I've always done, has always worked, and that's
> > what the documentation tells me to do in 12501 Security Guide:
> >
> > "
> > Step 1: Import server certificate and intermediate CA certificates
> >
> > ...
> >
> > The order is important. The server certificate should be imported before
> > the intermediate CA certificate.
> >
> > The same file name should be used (chain2cert in this example) when
> > importing both the server and intermediate CA certificate."
> >
> > > You need to use:
> > >
> > > ssl profile www.something.com
> > > keypair-file yourkey.key
> > > certificate-file yourcert.crt
> > > ca-cert-file your-cert-ca-chain.crt
> > > enable-certificate-chaining
> >
> > As I understand it, ca-cert-file is only required for verifying the certs
> > of connecting clients, which I am not doing.
> >
> > My process has worked fine for various other certs and CAs. This one is
> > different in that it is the first signed by this CA. I have also uploaded
> > the CA root cert for use in the ssl-proxy line. I have re-downloaded from
> > the CA the intermediate cert for inclusion (I had some trouble getting
> > that uploaded, I think perhaps a missing newline at the end was causing
> > the problem).
> >
> > An example of a working config for us is:
> >
> > ssl profile nemo-toclients
> > keypair-file nemo_2015.key
> > certificate-file nemo_chain_2015.crt
> > cipher-suite all-cipher-suites
> > enable-certificate-chaining
> > session-cache off
> >
> > ssl profile entrust2048-server
> > cipher-suite all-cipher-suites
> > disable ssl2 ssl3
> > ca-cert-file entrust2048-ca.crt
> > session-cache off
> >
> > server virtual ex2010-cas-lb ...
> > predictor round-robin
> > port ssl sticky
> > port ssl ssl-proxy nemo-toclients entrust2048-server
> > port ssl csw-policy "exch2010a"
> > ...
> >
> > where nemo_chain_2015.crt contains the server cert and the intermediate,
> > and entrust2048-ca.crt is the CA root which issued. The clients get the
> > cert + intermediates.
> >
> > Replicating this for this new certificate/intermediate and CA is what is
> > failing for me.
> >
> > Danke or the thoughts, but I'm not sure it has helped yet.
> >
> > Jethro.
> >
> >
> >
> > >
> > >
> > > Cheers,
> > > Jonas
> > >
> > >
> > >
> > > Am Montag, den 09.11.2015, 16:05 +0000 schrieb Jethro R Binks:
> > > > Hi,
> > > >
> > > > I'm banging my head against a wall here and looking for some help.
> > > >
> > > > One virtual service is having a cert change due to expiry, and I've got
> > > > the .pfx as exported from Windows. I have extracted the key and cert from
> > > > this. I have the intermediate and root certs.
> > > >
> > > > I can upload all, the key to the keyfile, and the host cert then the
> > > > intermediate to the cert file using scp. Done this some number of times
> > > > in the past routinely.
> > > >
> > > > I can use the show commands to view the cert chain, and see the host's
> > > > cert plus the intermediate.
> > > >
> > > > However what I can't do is the actual bind of the cert into the ssl
> > > > profile:
> > > >
> > > > SSH@sender(config)#ssl profile tcnemo-toclients
> > > > SSH@sender(config-ssl-profile-tcnemo-toclients)#keypair-file tcnemo_2015.key
> > > > SSH@sender(config-ssl-profile-tcnemo-toclients)#certificate-file tcnemo_chain_2015.crt
> > > > SSH@sender(config-ssl-profile-tcnemo-toclients)#Error key and certificate mismatch
> > > > Please delete the key and re-add the right key and certificate
> > > > SSL profile : tcnemo-toclients
> > > > Certificate file : \usb0\certstor\tcnemo_chain_2015.crt.cert
> > > > Key file : \usb0\certstor\tcnemo_2015.key.key
> > > >
> > > > The only help I can get from Dr Google is the suggestion from the
> > > > documentation that this key does not match the certificate. But both came
> > > > from the exported PFX, and I've verified them manually in various ways.
> > > > Now totally stuck as to what to do next (and time is ticking for the
> > > > previous cert expiry :).
> > > >
> > > > Anyone any ideas?
> > > >
> > > > ADX 12.5.01g
> > > >
> > > > Jethro.
> > > >
> > > > . . . . . . . . . . . . . . . . . . . . . . . . .
> > > > Jethro R Binks, Network Manager,
> > > > Information Services Directorate, University Of Strathclyde, Glasgow, UK
> > > >
> > > > The University of Strathclyde is a charitable body, registered in
> > > > Scotland, number SC015263.
> > > > _______________________________________________
> > > > foundry-nsp mailing list
> > > > foundry-nsp@puck.nether.net
> > > > http://puck.nether.net/mailman/listinfo/foundry-nsp
> > >
> >
> > . . . . . . . . . . . . . . . . . . . . . . . . .
> > Jethro R Binks, Network Manager,
> > Information Services Directorate, University Of Strathclyde, Glasgow, UK
> >
> > The University of Strathclyde is a charitable body, registered in
> > Scotland, number SC015263.
> > _______________________________________________
> > foundry-nsp mailing list
> > foundry-nsp@puck.nether.net
> > http://puck.nether.net/mailman/listinfo/foundry-nsp
>

. . . . . . . . . . . . . . . . . . . . . . . . .
Jethro R Binks, Network Manager,
Information Services Directorate, University Of Strathclyde, Glasgow, UK

The University of Strathclyde is a charitable body, registered in
Scotland, number SC015263.
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp