Chrome Update 58 Breaks FortiAuthenticator CA Certs

[theFWdude]

I'm currently leveraging my FAC as a "stand alone" CA server and used it to "Sgin" my Fortigate Web Admin Certificates; however last night my Chrome Browser (and assuming other users) updated and now I get the following error:

This server could not prove that it is myfirewall.mydomain.com; its security certificate is from [missing_subjectAltName]. This may be caused by a misconfiguration or an attacker intercepting your connection

Browser Info: Google Chrome Version 58.0.3029.81 (64-bit)

Given that my Gates are not joined to the domain, they do not have a "UPN" or email address so I don't really know how to leverage SAN certificates for them.

Just checking to see if anyone else is currently experiencing this issue as well.

[theFWdude]

Updated my case awaiting to hear back.  Even when the Gate submits the CSR with a "Subject Alternative Name" the .cert is actually missing the SAN portion of the cert.

[theFWdude]

Anyone else been able to get this working?  I seem to to be getting nowhere with support.

[Bromont_FTNT]

Looks like this (SAN) will be added to v5, still at least a few weeks away from release.

[theFWdude]

So.. crickets so far..  a "Few Weeks" isn't really a great response for my boss.  Got any dates or any confirmed road map plans?  Seriously.. I'm relying on the FAC to provide me trusted certificates and my current Inspection Profiles and are broken.. 

[emnoc]

When  the SANs  issues finally  get resolve will someone verify how many altNames it can sign  5 ,10 , 25 or more.? I've seen weird things where  within  CSR that where crafted  & with  altname and after so many the signer will ignore the rest of the altNames.

e.g  classic openssl  CNF the last 2 ALtName would be dropped.

[v3_req] basicConstraints = CA:FALSE keyUsage = keyEncipherment, dataEncipherment, Digital Signature, Non Repudiation subjectAltName = @alt_names extendedKeyUsage = serverAuth,clientAuth

[alt_names] DNS.1 = potatoe1.example.com

DNS.2 = potatoe2.example.com

DNS.3 = potatoe3.example.com

DNS.4 = potatoe4.example.com

DNS.5 = potatoe5.example.com

DNS.6 = potatoe6.example.com

DNS.7 = potatoe7.example.com

So the FTNT should list what the max AltNames value.

And lastly, If the FortiAuthenticator has the means to export the rootCAkey  , can  you just manually use  openssl to sign the altName  CSRs as a work-around till the appliance os is fixed?  Maybe the cli has the means to extract the  rootCAkey and with the rootCAcertfile you can do the signing as a temporal fix.

Just an ideal don't know what all a authenticator can or can not do.

;)

Ken

[theFWdude]

Ken,

Quick question.. other than experience do you have any good recommended reads on PKI?  I seriously need a "101" when it comes to PKI administration.. No so much the "math" side of the house, but more of the implementation and administration of it.  FAC guide has only provides vague information.   Thanks in advance!

[emnoc]

If your talking about the FAC, read the doc. I 've only used it like twice and have not kept up on what it all can do on the PKI side.

if your talking about  good read for PKI, rad openssl manpages or youtube and google searches. I have a few PKI  post tip/tricks using openssl going back 5+  years on various blogs and forums. Openssl is the king in finding out alot on what you can and can do with PKI.

We have private inhouse CAs that seems to treat various attributes or AltNames  differently but I'm sure if you craft a CSR with AltNames read it back in  via openssl

e.g

openssl req -in  <csrname.file> -noout -text  and review the ALtName  field.

Then if you can extract the FAC priv-key and export the certificate, you should be able to sign the said  csrname.file with those two items.

e.g

openssl x509 -req  -days 366 -in <csr_with_altnams.csr>  -CA FACroot.crt -CAkey FACCA.key -oout namedgeneratecertificate.crt