NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
M4300-28G (GSM4328S) HTTPS Admin "ERR_SSL_PROTOCOL_ERROR"
Netgear support seems to be unable to figure this out, so I'm hoping someone in the community can. I'm trying to enable the HTTPS Admin Interface, but the switch seems to only give me protocol errors...
With atian's help, I have found the solution.
In addition to "pem format" and "include the private key with the server certificate", any chain CA certficates must be appended to the server certificate file, not the trusted root file, and the Trusted root pem file should only contain the root. Doing this has resulted in the switch properly serving HTTPS and a complete chain of trust to the root CA in my computer's trust store.
I want to be VERY clear here, though. Other than "PEM Formatted", no other guidance or information is offerred in any documentation I was able to find or anything offered by support. Nowhere does it say that the private key is to be prepended to the "Server Certificate PEM file", nor does it offer guidance on where to add or append or upload CA chain files (many systems I've used before use separate files for the server private key, the server certificate, and the CA chain certs). This REALLY needs to be documented, and would have saved me two and a half months struggling with support that doesn't have a clue about how this is supposed to work, either (I'm guessing the internal documentation doesn't mention this, either).
Unfortunately, TLS 1.0 is enabled by default, as is SSL 3.0. I've attempted the same steps with SSLv3.0 disabled, but the result is the same.
It is good to hear that TLS 1.2 is "in the works", though it is worth mentioning that Chrome does support TLS 1.0, so things should be working, but Chrome, FireFox, and OpenSSL s_client all return protocol errors.
I've attached the output of running testssl.sh to this ticket. Strangely, this seems to show that the switch is seeming to support TLS 1.1 and TLS 1.2? Either way, double checking OpenSSL s_client and forcing -tls1 still shows the same protocol errors:
139847755073176:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long:asn1_lib.c:157:
139847755073176:error:0D068066:asn1 encoding routines:ASN1_CHECK_TLEN:bad object header:tasn_dec.c:1205:
139847755073176:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:386:Type=X509
139847755073176:error:1409000D:SSL routines:ssl3_get_server_certificate:ASN1 lib:s3_clnt.c:1237:
Which would, to me, seem to indicate that the switch is manipulating or munging the certificate in some way before it sends it. I'll re-iterate that prior to uploading the cert/key to the switch, I am able to locally verify the certificate (in PEM format) using OpenSSL, and have generated and installed certs using the same methods to multiple other services/applications (RabbitMQ, Apache, etc).
Either the switch is expecting some non-standard format or has some extra requirements that aren't called out in the documentation (and aren't checked for on upload or on attempt to activate the HTTPS Admin interface), or something is severely broken in the SSL/TLS implementation (or some combination of both). I'm really hoping I'm just doing it wrong, but so far I've been unable to verify that, and the documentation offers no guidance on how to do this at all (neither has support, for that matter), so I'm kinda stuck hoping I can find someone who can point me in the right direction.
To add some further detail to this issue, as best I can tell by the errors in OpenSSL and from in Firefox, it looks as though the switch is mangling the certificate it sends to the browser. I've tried generating a new cert and re-uploading to the switch (via TFTP), but have again been met with the same errors. The switch does seem to check/validate the uploaded combined certificate/key file, but I'm guessing it is only checking that it is in valid PEM format. I haven't tried any other signature algorithms or keylengths (I've been sticking with 2048-bit keys and SHA256), but I doubt this is a problem as it should only matter to the client; the server (switch) shouldn't be touching that at all.
It would be nice to be pointed in some direction that gives some level of guidance on what formats or restrictions the switch has for the keys and other SSL-related files beyond just "PEM format" and "must be the correct format". For instance, nowhere does it mention how to upload the private key, I had to find that on StackOverflow that you need to append it to the Certificate file. It would be incredibly helpful if it was documented somewhere if there are restrictions/requirements on keylength, signature algorithms, DH params, etc. I've been unable to get this information from support (so far, the closest thing to a "response" I've gotten is "we Googled the error in Chrome, have you tried deleting your Hosts file?" which is pretty unhelpful in this context for this issue), and the documentation/manual is severely lacking anything that might be useful in this situation. At this point, any information that might be in anyway relevant would be appreciated or helpful (like the bit about TLS 1.1 and 1.2, even though it ultimately doesn't help in this case, that is very helpful/useful information).
Hi Brwyatt,
I didn't find the steps how you generate the chain_with_root.pem. How did you generate it?
Strictly speaking, that file is not "generated", it is the concatination of the root and intermediary CA certs, as is the usual standard.
You can see the file here: https://s3-us-west-2.amazonaws.com/netgear29767800/chain_with_root.pem
To parse all three certs (and also showing they are valid): `curl -s https://s3-us-west-2.amazonaws.com/netgear29767800/chain_with_root.pem |awk -v cmd='openssl x509 -noout -subject' '/BEGIN/{close(cmd)};{print | cmd}'`
This same file/format works for Apache and RabbitMQ (though, admittedly, the Root cert is usually ommitted and only the 2 intermediaries are needed (as the client will already have the Root in their trust store), but it works either way in Apache). I do want to stress here, I'm not getting "untrusted" errors in the browser. OpenSSL, FireFox, and Chrome are all returning errors indicating that the server (that is to say the switch) is sending back garbage. It appears to actually properly handshake, but then returns a malformed certificate.
Just heard back from support. No answers yet, but they had me double check the switch-generated key/cert and also a zip archive of key/cert and dhparams they generated.
I'm seeing some things standing out:
- Self-signed certs (I'm using a cert signed by a signing CA that has an intermediary CA and then a root CA)
- SHA1 (I'm using SHA256. SHA1 is considered untrusted by modern browsers!)
- 1024-bit keys (I'm using 2048-bit keys. Seriously, who uses 1024-bit?)
Nowhere in any documentation I've found has it said anything about restrictions on CAs, signature algorithms, or key length. But, if I had to guess, I'd place money on the key length, but this really should be checked when the key/cert is uploaded to the switch (it already checks it for other errors). If I had to guess, it is probably truncating the key and causing issues when sending the cert.
I've replied back to support with this info, so we'll see what they say. I don't really feel like re-generating and signing new certs until I hear back if this is, in fact, the issue. If it is, it would be really REALLY nice if this was actually documented anywhere and save someone else hours of effort and months of waiting for support to figure it out.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
