As was foretold, we've added advertisements to the forums! If you have questions, or if you encounter any bugs, please visit this thread: https://forums.penny-arcade.com/discussion/240191/forum-advertisement-faq-and-reports-thread/
Options
Trial SSL Certs. I'm dumb. HALP!
RoundBoy
Registered User regular
Registered User regular
I am trying to get a trial certificate from verisign to test a new secure FTP transfer.
I am using OpenSSL to create the certificate request.
>>> it goes to verisign
<<<< They send me back the verified cert.
>>> I cut & paste this into a text document cert.crt which I can now 'install'
..... i see it nowhere
Win2k3 server. I tried looking under IIS secuity.. but that shows no certs installed. My cert also has a yellow exclaimation point saying that it could not be verified as coming from verisgn...
are trial certs boorked ? Do I *really* need to just shell out the cash for a real one?
leeloo dallas multipass.
I am using OpenSSL to create the certificate request.
>>> it goes to verisign
<<<< They send me back the verified cert.
>>> I cut & paste this into a text document cert.crt which I can now 'install'
..... i see it nowhere
Win2k3 server. I tried looking under IIS secuity.. but that shows no certs installed. My cert also has a yellow exclaimation point saying that it could not be verified as coming from verisgn...
are trial certs boorked ? Do I *really* need to just shell out the cash for a real one?
leeloo dallas multipass.
Librarians harbor a terrible secret. Find it.
RoundBoy on
0
Posts
That is, if you are creating a secure website, you need to create the cert request in IIS, then once you get the cert back, import it using IIS.
Unless OpenSSL is part of the secure FTP program you're using, you can't use it to generate the request. You also can't just add the cert to your local repository like I think you're doing. That's only for client-related functions, not server-related.
Which brings me to the next point, which is that AFAIK no version of IIS supports a secure FTP protocol. What are you using for that?
http://www.thelostworlds.net/
This is besides the point, as I will be using a java app to transfer via https..
AFAIK .. a cert is a cert... the web browser can use it or a ftp client can use it... its a self contained entity.. its either 'self signed' making it useless for anybody but you .. or it can be signed by verisign, etc.. for 3rd party proof.
When getting a cert signed .. do they really differentiate between ftp or web ?
As for generating the request ... isn't the request just a hashed mashup of all the information you are giving (name, company, etc)?
Librarians harbor a terrible secret. Find it.
a cert isn't a cert. there are multiple kinds for multiple things. self signed are the same as from any entity out there - but verisign and the others have been pre-trusted by microsoft so you don't have to add them to the local cert store.
Now I'm a bit rusty with the pki and the hippity-hop and the brittney spearses you kids are all into, but I though that the verisign cert WAS NOT for ssl/authentication/what have you, but only for signing other certs that you'd use on the web server or for secure email or whatever.
Is this using FTP, or HTTPS? You mention CuteFTP (who sell a secure FTP product), but also Java and HTTPS, which is completely different.
I can't say definitively that there's no way to make a request for a cert using one application and then import the response back into a different one, but every doc I've ever read indicates that you should make the request using the same app that the cert will be used in. I assume it has to do with the way that the request is signed.
What you will need to do is pick your server software before you can make use of the certificate. Although you can import certs into the Windows cert store itself, that is useless as far as every piece of server software I've used. IIS has its own store of certs that you import the server cert into, for example. On the Java side of things, the JRE has keystores that I assume can be shared between applications, but you still have to use the Java keystore and not the Windows one, and you have to point the Java-based applications to the keystore file that you create using the JRE utilities.
There are a lot of different types of cert out there. Web servers use X.509 certs. I don't know what secure FTP products use because AFAIK there still is not a standard for secure FTP, only a couple of competing drafts.
The short answer to your question is that you need to pick the server software you're going to be using, and then follow the vendor's instructions for requesting a cert and then importing it back into their software when you get the response.
http://www.thelostworlds.net/
It's technically possible to get a cert like that, but very difficult and expensive. Well beyond the reach of individuals and most corporations.
Most certs are the kind that are used directly - either on a server to enable secure communication or on the client side as "proof" to the server that the client is trusted.
http://www.thelostworlds.net/
We have a vendor who now wants us to get files over HTTPS via a java application and SSL.
I used OpenSSL to generate a certificate request with our company name, contact, etc... all the standard stuff.
because I am really just the middle man here, i don't as of yet have all the budget, approvals, etc to fully implement this ... but it needs to work VERY soon.. hence the use of a trial 14 day cert from verisign.
Is my understanding of SSL certs completely wrong? I was under the impression that you create a certificate identifying your server... and send it to some 3rd trusted 3rd party, who then signs it as 'valid'... its nothing more then proof that I am who I say I am, no ?
This is what I have already done... it just so happens that the certificate i have 'signed' says "Windows does not have enough information to verify this certificate"
What I think is happening is that verisign for trial certs needs ANOTHER intermediate signing... to prevent an abuse of the system... What this results in is a absolute mess of certifications on top of certifications..
I am of the thinking that a 'real' 2 year certificate would simply be my request validated... no 3rd authentication needed.. and its ready to go.
That being said... if i generated a certificate with my info.. and its 'validated' ... what is the difference if I use it for a webserver for to authenticate a SFTP session? For what its worth.. I do have to convert it to an x509 cert for use.. is that limiting me to https only ?
Librarians harbor a terrible secret. Find it.
Last time I looked (y2k?) I'm sure the practice was to get the cert, install it as the root CA, and use that to sign the another CA, then take the root off-line and vault it to prevent the root from being compromised in the event you needed to revoke part of the chain. This was for an enterprise PKI though so probably doesn't apply here.
As in "you connect to them via SSL and get files"? If you are connecting to them, I don't see where you need a cert from verisign at all unless the company your connecting to requires it for authentication. In which case they should have done this before and should be able to give you more guidance.
Yeah .. you would think.. Only there is a nice language barrier preventing a decent q/a session... which doesn't really matter... because i am following the instructions they are giving me to the letter.
I think it goes back to that 3rd authentication level the trial cert wants.
Its all BS anyway.. i might as well just sign the cert myself.. its not like they are authenticating me...
Is that you?
yes.
Ok.. come get files.
File transfer over HTTPS is a bunch of BS anyway... its not designed to handle file transfers like ftp is. Keep your HTTPS... i'll just continue to use my FTP user/pwd and get the PGP encrypted files...
Im sure the PGP is doing leaps and bounds more for security then HTTPS
Librarians harbor a terrible secret. Find it.
Yes, that is the procedure. But unless you can convince one of the existing public cert authorities to give you a cert that allows you to then sign other public certs, all you can use it for is internal use, not signing certs for use on public websites.
RoundBoy, you might be running into an issue with the intermediate cert or possibly an expired root CA if you are on XP. However, again, adding certs to the Windows cert collection isn't going to do you any good for getting a file via HTTPS.
To fix the former is kind of complicated. I can't find the documentation anywhere on this, so here it is from memory:
1 - Open the cert in the Windows cert viewer.
2 - Click on the Certification Path tab.
3 - If one of the steps has a red X, this may work for you. If none of them do, skip the rest of the steps.
4 - Select the step which had a red X. Click the View Certificate button.
5 - Click the Details tab. Click the Copy to File button.
6 - Use the wizard to save the cert. I think you want Base 64-encoded, but it might be DER instead.
7 - Open the cert you just exported in Notepad. Copy the contents.
8 - Make a copy of the file containing the cert you got back from Verisign (since you don't want to alter the original).
9 - Open that copy in Notepad. Paste the contents that you copied in step 7 at the end of the file, save and close.
10 - Import the Frankenstein monster cert you just created.
To fix the latter: http://www.annoyances.org/exec/forum/winxp/t1073942207
Have you tried just getting the file via HTTPS without doing any of this cert stuff on your end? Like PirateJon said, it shouldn't be necessary for you to do anything since you're operating as the client.
Addition: Yes, PGP is better overall.
http://www.thelostworlds.net/