Tiny Deathstars of Foulness

The default, self-signed certificate that comes on a SonicWALL causes alerts during a Nessus scan. This is because the device uses a certificate that comes on the device and isn’t signed by a valid CA. Chances are, there are limits around who can load the SonicWALL web interface in the first place. But, if you don’t want Nessus to continue alerting, or if you just want to use a certificate signed by a valid CA because it’s a good security practice, you might want to add a new certificate. The first step is to generate a new CSR. To do so, open the SonicWALL web interface and then click on System in the SonicWALL sidebar. Then click on Certificates and scroll to the bottom of the screen until you see the New Signing Request button. At the resultant Certificate Signing Request screen, fill out the fields with your information. Click on the Generate button to bring up the Export Certificate screen. Click Export and then choose where to save the CSR. Once you receive the certificate, you’ll want to install it. The easiest way to do so is to go back to the Certificates screen (under System in the SonicWALL sidebar) and then scroll down to the bottom, clicking on Import… Here, use Choose File to pick the cert, provide a name for it and the password for it and click on Import. Next, click on Administration (also under System in the SonicWALL sidebar). Scroll down to the Web Management Settings section of the screen and use the Certificate Selection field to select the newly installed certificate. And that’s it. I’ve had to restart the device to get it to work properly, but overall, a pretty straight forward process.

January 7th, 2012

Posted In: Network Infrastructure

Tags: , , , , , ,

Recently, I did an article for where I explained that you can import a pkcs12 file into an 802.1x profile using networksetup. In that type of environment you would be leveraging TLS or TTLS with the Mac OS X client acting as the supplicant and the certificate required to establish authentication with the authenticator. So you need the certificate to get started, but how do you get the pkcs12 and dish it out to clients programatically? We’re going to start out with a new keychain where we’ve imported the certificate into that keychain (or skip this step if you already have a p12 file). First, find the certificate and verify the name, as this is very important to networksetup. For this, I like to use the security command’s find-certificate option. Here we’re going to look for
security find-certificate -c
Now we’ll use the export verb of the security command to dump a .p12 file from the specially created keychain called 8021xkey,keychain to my desktop:
security export -k 8021xkey.keychain -t certs -f pkcs12 -o ~/Desktop/krypted.p12
When run you’ll be asked for a password to give the new p12 for decryption. Once we have the keychain it can easily be imported, as we will do from the desktop of a client system:
security import ~/Desktop/krypted.p12 -f pkcs12
Now we can use the p12 along with the -settlsidentityonsystemprofile or -settlsidentityonuserprofile. For example (using the default AirPort as the service and mysecretpassword as the password to decrypt the p12):
networksetup -settlsidentityonsystemprofile AirPort ~/Desktop/krypted.p12 mysecretpassword
Overall, at this point you can finally automate the process of setting up the 802.1x aspect of a deployment using a script or a package. Simply setup profiles at the GUI, import them into the new computer (assuming you have setup the service names before hand) and if need be import the certificate. Much testing required though…

September 9th, 2009

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , , ,