[f-nsp] problems binding new key and cert on ADX

Jethro R Binks jethro.binks at strath.ac.uk
Tue Nov 10 11:07:36 EST 2015 

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 at sender(config)#ssl profile tcnemo-toclients
> > > > SSH at sender(config-ssl-profile-tcnemo-toclients)#keypair-file tcnemo_2015.key
> > > > SSH at sender(config-ssl-profile-tcnemo-toclients)#certificate-file tcnemo_chain_2015.crt
> > > > SSH at 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 at 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 at 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.

More information about the foundry-nsp mailing list