如何从GoDaddy导入证书以进行Java代码签名?

时间:2021-02-10 07:12:04

I need to be able to sign jar files with a certificate from a CA.

我需要能够使用来自CA的证书来签署jar文件。

I following the instructions from GoDaddy's documentation on how to do this: http://support.godaddy.com/help/article/4780/signing-java-code

我按照GoDaddy的文档说明如何执行此操作:http://support.godaddy.com/help/article/4780/signing-java-code

However, step 3 requires importing a cert file obtained from GoDaddy's web site. Per the documentation, the command is:

但是,步骤3需要导入从GoDaddy网站获取的证书文件。根据文档,命令是:

keytool -import -trustcacerts -keystore codesignstore -storepass <yourstorepwd> -alias codesigncert -file mycert.cer

Although I successfully submit the CSR (generated by keytool) and get a response, I can't for the life of me figure out how to get the mycert.cer file. There is an option to download a PEM file. But after running the above command, I get the error "keytool error: java.lang.Exception: Incomplete certificate chain in reply". I've tried this multiple times, and double-checked I'm using the proper keystore. I've even tried re-keying using both SSH-1 one time, and then SSH-2 the other time. According to this person (https://*.com/questions/20793254/signing-a-jar-the-signers-certificate-chain-is-not-validated?rq=1), they were able to at least successfully import the PEM file. But I'm not sure if this is even the right approach.

虽然我成功提交了CSR(由keytool生成)并获得了响应,但我无法终身了解如何获取mycert.cer文件。可以选择下载PEM文件。但是在运行上面的命令后,我收到错误“keytool error:java.lang.Exception:Incomplete certificate chain in reply”。我已多次尝试过,并仔细检查我是否正在使用正确的密钥库。我甚至尝试过使用SSH-1重新键入一次,然后再使用SSH-2重新键入。根据这个人(https://*.com/questions/20793254/signing-a-jar-the-signers-certificate-chain-is-not-validated?rq=1),他们至少能够成功导入PEM文件。但我不确定这是否是正确的方法。

GoDaddy's tech support has been absolutely dreadful. Most of the techs I've talked to aren't familiar with keytool at all, and it took me several tries calling them before they forwarded me to their SSL department (480-505-8852), which is at least marginally better than general support.

GoDaddy的技术支持绝对可怕。我所谈到的大多数技术人员根本不熟悉keytool,在他们转发给他们的SSL部门(480-505-8852)之前,我花了好几次尝试打电话给他们,这至少比一般情况要好一些。支持。

If I use Internet Explorer or Firefox, I believe I can automatically generate a CSR instead of creating one through key tool. Then I'd export the certificate through the web browser. From reading various other online documents, I believe I could then use openssl to convert to the proper format for keytool. I'm not sure on the details of how this will work yet, but I don't see any other options.

如果我使用Internet Explorer或Firefox,我相信我可以自动生成CSR而不是创建一个通过密钥工具。然后我将通过Web浏览器导出证书。从阅读各种其他在线文档,我相信我可以使用openssl转换为keytool的正确格式。我不确定这将如何工作的细节,但我没有看到任何其他选择。

Has anyone been successful with this or have any pointers on how to proceed? I found a similar question here (Signing a java applet with an spc file from GoDaddy), but the answer simply points me to GoDaddy's poor documentation. I would use a another CA if I could, but I've already paid the money and gone through the long, drawn-out verification process.

有没有人成功的这个或有任何指示如何进行?我在这里找到了一个类似的问题(使用GoDaddy的spc文件签署一个java小程序),但答案只是指向GoDaddy糟糕的文档。如果可以的话,我会使用另一个CA,但我已经付了钱,经历了漫长而漫长的验证过程。

10 个解决方案

#1


10  

The workaround is to contact GoDaddy and have them reissue your organization's certificate. During the certificate setup process, you must select a SHA-1 codesign certificate instead of SHA-2. The option to select SHA-1 will only be available if you certificate validity does not extend to 2016 (see below), so make sure they understand your end goal is to recreate your SHA-2 certificate as SHA-1, so they know to sell you a cert with the correct validity period.

解决方法是联系GoDaddy并让他们重新颁发您组织的证书。在证书设置过程中,您必须选择SHA-1协同代码证书而不是SHA-2。选择SHA-1的选项仅在证书有效期未延伸至2016(见下文)时才可用,因此请确保他们了解您的最终目标是将SHA-2证书重新创建为SHA-1,因此他们知道向您出售具有正确有效期的证书。

I traded my SHA-2 cert for a SHA-1 today, and GoDaddy's Java Code Signing instructions worked perfectly.

我今天将SHA-2证书交换为SHA-1,GoDaddy的Java代码签名说明完美无缺。

GoDaddy informed me Keytool may have trouble importing a certificate response chain generated from their SHA-2 (2048 length) codesign certificate. I withhold judgment of Keytool since it imports SHA-2 certs fine when the GoDaddy's root SHA1 cert is lopped from the pem file per @mogsie's answer.

GoDaddy告诉我,Keytool可能无法导入从其SHA-2(2048长度)协同代码证书生成的证书响应链。我保留对Keytool的判断,因为当根据@mogsie的答案从gom文件中删除GoDaddy的根SHA1证书时,它会导入SHA-2证书。

GoDaddy goes with SHA-2 automatically when it grants codesign certificates that will extend into 2017 because Microsoft will not accept less than SHA-2 beginning January 1, 2016, so if you're in the market for a SHA-1 certificate, it will have short-term validity.

GoDaddy在授予将延长到2017年的代码签名证书时会自动使用SHA-2,因为从2016年1月1日开始微软不会接受少于SHA-2,因此如果您在市场上获得SHA-1证书,它将会具有短期效力。

The issue might go away with a Java Keytool update (I was working with 1.6), or if GoDaddy's Sha256withRSA self-signed certificate becomes widely trusted.

Java Keytool更新(我使用1.6)或GoDaddy的Sha256withRSA自签名证书变得广泛受信任,这个问题可能会消失。

#2


5  

The answer, as mentioned by Waterbear, is to have your GoDaddy cert reissued or rekeyed by GoDaddy using SHA-1. The reason is that GoDaddy has two CA servers: Class 2 CA which is used for signing SHA-1 certificates, and G2 CA which is used for signing SHA-2 certificates. While the older Class 2 CA is trusted by the Java Truststore (and thus SHA-1 certificates are trusted), the newer G2 CA is not, so its SHA-2certificates are not trusted unless you manually install its root certificate (which defeats the purpose of buying a cert in the first place). Hopefully GoDaddy's G2 CA becomes trusted by the Java Truststore soon (Before 2016!), but until that happens a GoDaddy SHA-2 cert is no better than a self-signed cert.

正如Waterbear所提到的,答案是让GoDaddy使用SHA-1重新发布或重新设置你的GoDaddy证书。原因是GoDaddy有两个CA服务器:用于签署SHA-1证书的Class 2 CA和用于签署SHA-2证书的G2 CA.虽然旧的Class 2 CA受Java Truststore信任(因此SHA-1证书是受信任的),但较新的G2 CA不受信任,因此除非您手动安装其根证书(这违背了目的),否则其SHA-2证书不受信任首先购买证书)。希望GoDaddy的G2 CA很快就会受到Java Truststore的信任(2016年之前!),但在此之前,GoDaddy SHA-2证书并不比自签名证书更好。

#3


5  

Since I enjoyed (not) the process of creating a codesinging certificate so much, I thought I would share the process I went thru, and hopefully when you need to generate your own, this will save you some of the heartache and pain .

由于我非常喜欢(不)创建代码验证证书的过程,我想我会分享我通过的过程,并希望当你需要生成自己的过程时,这将为你节省一些心痛和痛苦。

I used godaddy , but I have to believe whoever the CA is the steps should be very similar.

我使用的是godaddy,但我必须相信CA的步骤应该非常相似。

These are the steps I went thru:

这些是我通过的步骤:

(note that godaddy does not create a codesigning certificate in jks format and there is an extra step involved to convert the keystore to jks)

(请注意,godaddy不会以jks格式创建代码签名证书,并且还需要额外的步骤将密钥库转换为jks)

Create keystore:

keytool -genkey -alias codesigncert -keypass yourpassword -keyalg RSA - keysize 2048 -dname "cn=server1.lccc.edu, OU=College Name , O=College Name , L=Schnecksville, ST=Pennsylvania,C=US" - keystore /home/oracle/codesignstore/codesignstore -storepass yourpassword -validity 720 (storepass and keypass can be the same)

keytool -genkey -alias codesigncert -keypass yourpassword -keyalg RSA - keysize 2048 -dname“cn = server1.lccc.edu,OU = College Name,O = College Name,L = Schnecksville,ST = Pennsylvania,C = US” - keystore / home / oracle / codesignstore / codesignstore -storepass yourpassword -validity 720(storepass和keypass可以是相同的)

Generater crt for godaddy

keytool -certreq -v -alias codesigncert - file /home/oracle/codesignstore/codesignstore.pem - keystore /home/oracle/codesignstore/codesignstore

keytool -certreq -v -alias codesigncert - file /home/oracle/codesignstore/codesignstore.pem - keystore / home / oracle / codesignstore / codesignstore

using an editor open codesignstore.pem and paste it into the godaddy site

when godaddy verifies the account and you pay your money the 'pending' status will go away

当godaddy验证帐户并且您付款时,“待处理”状态将消失

go to your godaddy account (https://mya.godaddy.com/)

去你的godaddy帐户(https://mya.godaddy.com/)

click on myaccount at the top of the page (in the black header)

点击页面顶部的myaccount(在黑色标题中)

click on manage SSL Certificates

单击“管理SSL证书”

select the codesigning certificate listed

选择列出的代码签名证书

click on the Launch button

单击“启动”按钮

download the file as a PEM file

将文件下载为PEM文件

save it on your local pc

将它保存在您的本地电脑上

open firefox, in the advanced section select view certificates, and the

certificate should be listed on the managed views.

证书应列在托管视图上。

highlight the certificate and select backup (export) and save it as a pkcs12 file

突出显示证书并选择备份(导出)并将其另存为pkcs12文件

click on view certificates at the top of the screen next to certificate viewer is the alias in double quotes, right this down it will be the alias to be used on the jarsigner command below

单击证书查看器旁边的屏幕顶部的视图证书是双引号中的别名,右下角它将是下面的jarsigner命令中使用的别名

copy the file to the server where the codesigning certificate is going to be

used: (e.g server1 /home/oracle/code_sign_cert_from_godaddy/ godaddy_pkcs12.p12) * this is the new keystore

used :(例如server1 / home / oracle / code_sign_cert_from_godaddy / godaddy_pkcs12.p12)*这是新的密钥库

since the keystore has to be of the type jks, and godaddy does't create a jks file it has to be converted to jks format

因为密钥库必须是jks类型,而且godaddy不会创建jks文件,所以必须将其转换为jks格式

convert pcks12 to jks

keytool -importkeystore - srckeystore /home/oracle/code_sign_cert_from_godaddy/godaddy_pkcs12. p12 -srcstoretype pkcs12 - destkeystore /home/oracle/code_sign_cert_from_godaddy/godaddy_jks.jks -deststoretype jks

keytool -importkeystore - srckeystore / home / oracle / code_sign_cert_from_godaddy / godaddy_pkcs12。 p12 -srcstoretype pkcs12 - destkeystore /home/oracle/code_sign_cert_from_godaddy/godaddy_jks.jks-deststoretype jks

jar file processing:

unsign jacob.jar... i copied the jacob.jar file to a test directory /test_jacob and renamed it jacob1.jar (note 760815.1)

unsign jacob.jar ...我将jacob.jar文件复制到测试目录/ test_jacob并将其重命名为jacob1.jar(注760815.1)

jar xf jacob1.jar

jar xf jacob1.jar

extracts into "com" and "META-INF" folders, remove the "META-INF" folder

提取到“com”和“META-INF”文件夹,删除“META-INF”文件夹

remove the old jacob1.jar

删除旧的jacob1.jar

recreate the jacob1.jar from the /test_jacob directory

从/ test_jacob目录重新创建jacob1.jar

jar -cvf jacob1.jar *

jar -cvf jacob1.jar *

run jarsigner -verify jacob1.jar, should show unisigned.

运行jarsigner -verify jacob1.jar,应该显示unisigned。

create a text file call mymanifest.txt

创建一个文本文件,调用mymanifest.txt

  Permissions: all-permissions

  Codebase: *

  Application-Name: OracleForms

jar -ufm jacob1.jar mymanifest.txt (this puts the new manifest info into the jar file)..

jar -ufm jacob1.jar mymanifest.txt(这会将新的清单信息放入jar文件中)

you can open jacob1.jar with the unzip jacob1.jar -d directory where unzip will reside to verify that the mymanifest.txt file is now part of the jar file.

你可以使用unzip jacob1.jar -d目录打开jacob1.jar,其中unzip将驻留在该目录中以验证mymanifest.txt文件现在是jar文件的一部分。

sign jar file

jarsigner - keystore /home/oracle/code_sign_cert_from_godaddy/godaddy_jks.jks - storepass yourpassword - signedjar /home/oracle/Oracle/Middleware/Oracle_FRHome1/forms/java/tes t_jacob/Signedjacob1.jar jacob1.jar "lehigh carbon community college's godaddy.com, inc. id" (this alias came from the firefox process above)

jarsigner - keystore /home/oracle/code_sign_cert_from_godaddy/godaddy_jks.jks - storepass yourpassword - signedjar / home / oracle / Oracle / Middleware / Oracle_FRHome1 / forms / java / tes t_jacob / Signedjacob1.jar jacob1.jar“lehigh carbon community college's godaddy.com ,inc.id“(这个别名来自上面的firefox进程)

the -signedjar file option was required, without it I was getting errors

note the alias is always the last entry on the jarsigner command and

there is no –alias option as there was on the keytool command

keytool命令没有-alias选项

verify jar file is signed

jarsigner -verify Signedjacob1.jar will display:

jarsigner -verify Signedjacob1.jar将显示:

jar verified.

jar验证。

show whats in the jar file

jar -tvf Signedjacob1.jar

jar -tvf Signedjacob1.jar

the .SF file is insided the .jar file, the .DSA file is replaced by the .RSA

file which is also inside the .jar file

文件也在.jar文件中

from the output of the jar -tvf Signedjacob1.jar

2721 Mon May 05 15:57:08 EDT 2014 META-INF/LEHIGH_C.SF

2721 Mon May 05 15:57:08 EDT 2014 META-INF / LEHIGH_C.SF

4231 Mon May 05 15:57:08 EDT 2014 META-INF/LEHIGH_C.RSA

4231 Mon May 05 15:57:08 EDT 2014 META-INF / LEHIGH_C.RSA

I copied the Signedjacob1.jar file to the $ORACLE_HOME/forms/java directory and then using the

我将Signedjacob1.jar文件复制到$ ORACLE_HOME / forms / java目录,然后使用

login to the weblogic enterprise manager

登录weblogic企业管理器

I changed the webutilarchive parameter from Jacob.jar to Signedjacob1.jar for each instance

我为每个实例将webutilarchive参数从Jacob.jar更改为Signedjacob1.jar

( em >>forms>>web configuration >> instance name >> all (the first entry should be the archive parameter)

(em >> forms >> web配置>>实例名>> all(第一个条目应该是archive参数)

When changing the jacob.jar to the Signedjacob1.jar , I did it for each of my test instances before I did it for production, just in case.

将jacob.jar更改为Signedjacob1.jar时,我为每个测试实例执行了此操作,然后再进行生产,以防万一。

Stop and start wls_forms and you should be good to go..

停下来开始wls_forms,你应该好好去......

#4


2  

@Waterbear Thanks so much for your solution about getting an SHA-1 certificate instead of SHA-2. This was definitely the problem I was having. (I would have posted this underneath your comment, but * said it was way too long.) I had gotten a 3-year certificate, and by default GoDaddy gives an SHA-2 for certificates expiring after a certain date. However, even when I re-keyed and asked for an SHA-1, I still ended up with an SHA-2. I had to revoke my certificate and then start the process from scratch to get an SHA-1 certificate. (By starting from scratch, I mean GoDaddy must again verify your company and phone number and all that.) By the way, if you do revoke your certificate, make sure you ask GoDaddy for permission first because technically they don't have to give you a refund. In addition, I wasn't able to get a 3-year certificate because anything that expires after a certain date (2016?) must be SHA-2 and not SHA-1. I basically had to get a refund for my 3-year certificate and instead get a 1-year certificate to even have the SHA-1 option. But after going with SHA-1, GoDaddy's instructions in approach#1 worked fine. I would recommend doing generating your CSR manually using the keytool command (instead of automatically through a web browser). Later, you just download the PEM file and import it into the keystore using the keytool command. (This is what GoDaddy's describes in "approach 1" in the link posted in the question.)

@Waterbear非常感谢您获得SHA-1证书而不是SHA-2的解决方案。这绝对是我遇到的问题。 (我会在你的评论下面发布这个,但是*表示它太长了。)我已经获得了3年的证书,默认情况下,GoDaddy会在特定日期之后颁发SHA-2证书。但是,即使我重新键入并要求使用SHA-1,我仍然使用SHA-2。我不得不撤销我的证书,然后从头开始获取SHA-1证书。 (从头开始,我的意思是GoDaddy必须再次验证您的公司和电话号码以及所有这些。)顺便说一句,如果您撤销证书,请确保先向GoDaddy申请许可,因为从技术上讲,他们不必给予你退款了。另外,我无法获得3年证书,因为在特定日期(2016年?)之后到期的任何内容必须是SHA-2而不是SHA-1。我基本上不得不获得3年期证书的退款,而是获得1年的证书甚至可以获得SHA-1选项。但是在使用SHA-1之后,GoDaddy在方法#1中的指示运行良好。我建议使用keytool命令手动生成CSR(而不是通过Web浏览器自动生成)。稍后,您只需下载PEM文件并使用keytool命令将其导入密钥库。 (这是GoDaddy在问题中发布的链接中的“方法1”中描述的内容。)

Lastly if you do have to have a certificate reissued, and go through this process again, I would highly recommend choosing another company besides GoDaddy for code-signing. Their tech support was absolutely horrendous. Their support techs even admitted to me they weren't trained in this. The hours spent on this issue greatly offset any money saved on the cert.

最后,如果您必须重新签发证书并再次执行此过程,我强烈建议您选择除GoDaddy之外的其他公司进行代码签名。他们的技术支持绝对是可怕的。他们的支持技术人员甚至向我承认他们没有接受过这方面的培训。在这个问题上花费的时间大大抵消了证书上节省的任何资金。

#5


1  

keytool -import -trustcacerts -keystore codesignstore -storepass <yourstorepwd> -alias codesigncert -file mycert.cer

First thing, you ** MUST HAVE ** the mycert.cer file. Otherwise, you do not have the ability to import the cert.

首先,你必须** mycert.cer文件。否则,您无法导入证书。

Get a "lay of the land" - What is in the current keystore file? We want to list (or show) what is in the keystore..

得到一块“土地” - 当前的密钥库文件是什么?我们想列出(或显示)密钥库中的内容..

keytool -list -v -keystore codesignstore

If it prompts you for the password, you can just press the ENTER key and it will bark about it not being trusted, but for expediency, it is fine.

如果它提示你输入密码,你可以按下ENTER键,它会咆哮它不被信任,但为了方便,它没关系。

If you want to "pump" the results into a text file..

如果要将结果“泵”到文本文件中..

echo.|keytool -list -v -keystore codesignstore > kstore_result.txt

Note: the echo. does like what I previously mentioned about "pressing ENTER" so don't become too attached to that. :)

注意:回声。就像我之前提到的关于“按ENTER”的那样,所以不要过于依赖它。 :)

keytool -genkey -alias codesigncert -keyalg RSA -validity 1825 -keysize 2048 -keypass <yourstorepwd> -keystore codesignstore -storepass <yourstorepwd>

Other options:

其他选择:

-genkey = generate a key
-keyalg RSA = use RSA's key alogorithm
-validity 1825 = how long is the key good for?  Primarily used with self-signed certs as the certs from verisign or Thawte have their own expiration
-keysize 2048 = Is this a 1024 or 2048-bit enryption?
-keypass <yourstorepwd>
-keystore codesignstore
-storepass <yourstorepwd>

Thing you have to be very careful of here and Support will not tell you about this.. If you try to import other certs alongside the existing ones, you need to be careful you don't botch the whole thing. :)

你必须非常小心这里,支持不会告诉你这个..如果你试图导入其他证书与现有的证书,你需要小心你不要把整个事情搞得一团糟。 :)

If you do have a problem of course, you can delete the alias and import again..

如果您确实遇到问题,可以删除别名并再次导入..

keytool -delete -alias codesigncert -storepass <yourstorepwd> -keystore codesignstore

One of the things that I like to do is to "stack" the command to be sure that I work down through the list.

我喜欢做的一件事就是“堆叠”命令以确保我在列表中工作。

For example, you have from Godaddy:

例如,你来自Godaddy:

keytool -import -trustcacerts -keystore codesignstore -storepass <yourstorepwd> -alias codesigncert -file mycert.cer

Then, I take each command and set it up like the following to "walk" down the list:

然后,我接受每个命令并将其设置为如下所示“向下”列表:

keytool
-import
-trustcacerts
-keystore codesignstore
-storepass <yourstorepwd>
-alias codesigncert
-file mycert.cer

Then, looking at this list, does my version of keytool support each of these? You have -import as the first..

那么,看看这个列表,我的keytool版本是否支持这些?你有 - 作为第一个进口..

I just ran keytool -help and I don't see: -import, but do see -importcert

我刚刚运行了keytool -help,我没有看到:-import,但确实看到了-importcert

There maybe an issue there?

那里可能有问题吗?

Oracle shows us.. http://docs.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html

Oracle向我们展示了.. http://docs.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html

So, you may have to make some adjustments..

所以,你可能需要做一些调整..

Here is one that I setup on on of our local Apache Tomcat servers (Windows):

这是我在本地Apache Tomcat服务器(Windows)上设置的一个:

%JAVA_HOME%\bin\keytool -delete -alias tomcat -storepass somepass -keystore %JAVA_HOME%\bin\.keystore

And then..

接着..

%JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA -validity 1825 -keysize 2048 -keypass somepass -keystore %JAVA_HOME%\bin\.keystore -storepass somepass
What is your first and last name?
  [Unknown]:  secure.someserver.com
What is the name of your organizational unit?
  [Unknown]:  COMPANY
What is the name of your organization?
  [Unknown]:  COMPANY
What is the name of your City or Locality?
  [Unknown]:  ANYTOWN
What is the name of your State or Province?
  [Unknown]:  MI
What is the two-letter country code for this unit?
  [Unknown]:  US
Is CN=secure.someserver.com, OU=COMPANY, O=COMPANY, L=ANYTOWN, ST=MI, C=US correct?
  [no]:  yes

Note: When you run this, you will not see if it is successful or not.

注意:运行此操作时,您将看不到它是否成功。

Let's start here and see what the results are..

让我们从这里开始看看结果如何......

#6


1  

I found that of the four certificates you get from the godaddy PEM download, the first one is the self-signed root certificate.

我发现你从godaddy PEM下载获得的四个证书中,第一个是自签名的根证书。

To see the chain (on unix):

要查看链(在unix上):

keytool -printcert -file response-from-godaddy.pem | grep -C1 ^Owner

The response shows the four certificates that make up the chain, all the way to the root.

响应显示构成链的四个证书,一直到根。

Certificate[1]:
Owner: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
Issuer: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
--
Certificate[2]:
Owner: CN=Go Daddy Root Certificate Authority - G2, OU=https://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
Issuer: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
--
Certificate[3]:
Owner: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
Issuer: CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
--
Certificate[4]:
Owner: CN=REDACTED
Issuer: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US

Apparently the first one is already in the Java standard cacerts as the trusted root certificate. The fact that it is in the .pem file trips keytool up.

显然,第一个已经在Java标准cacerts中作为受信任的根证书。它在.pem文件中的事实使keytool跳起来。

I struggled with the same problem rekeying a few times, and I got lucky:

我为同样的问题挣扎了好几次,我很幸运:

  • Open up the PEM file.
  • 打开PEM文件。
  • Delete the first block of ----BEGIN to ----END,
  • 删除---- BEGIN的第一个块到---- END,
  • Run your keytool -import on the file containing the remaining three certificates.
  • 在包含其余三个证书的文件上运行keytool -import。

Presto!

普雷斯托!

keytool -importcert -v -trustcacerts -keystore XXX -alias codesigning -file 234.pem

Result:

结果:

Certificate reply was installed in keystore
[Storing XXX]

#7


0  

Here's what I did..

这就是我做的......

keytool -v -genkey -dname "CN=XXX, OU=YYY, O=ZZZ, L=CCC, ST=SSS, C=US" -alias myKey -keypass abc123 -keystore myKeystore -storepass abc123 -validity 1096 -keyalg RSA -keysize 2048 -sigalg SHA1withRSA

keytool -v -genkey -dname“CN = XXX,OU = YYY,O = ZZZ,L = CCC,ST = SSS,C = US”-alias myKey -keypass abc123 -keystore myKeystore -storepass abc123 -validity 1096 -keyalg RSA -keysize 2048 -sigalg SHA1withRSA

keytool -certreq -keyalg RSA -keysize 2048 -sigalg SHA1withRSA -v -alias myKey -file mycsr.pem -keystore myKeystore -storepass abc123

keytool -certreq -keyalg RSA -keysize 2048 -sigalg SHA1withRSA -v -alias myKey -file mycsr.pem -keystore myKeystore -storepass abc123

Submit request (mycsr.pem) to GoDaddy, download PEM file (1b27b7d7a29a06.pem in this case).

将请求(mycsr.pem)提交给GoDaddy,下载PEM文件(本例中为1b27b7d7a29a06.pem)。

The downloaded PEM file contains my signed certificate along with others in the certificate chain. I found keytool would not accept the PEM file as downloaded. I had to remove my certificate from downloaded certificate. I did this via Key Store Explorer (http://keystore-explorer.sourceforge.net/) Use the "Examine a Certificate" option, open the PEM file received from Godaddy (1b27b7d7a29a06.pem) click on the your certificate (not one of the others from GoDaddy), click on "PEM", click on "Export". I named this certificate 1b27b7d7a29a06-mycert.pem.

下载的PEM文件包含我签名的证书以及证书链中的其他证书。我发现keytool不会接受下载的PEM文件。我不得不从下载的证书中删除我的证书。我通过Key Store Explorer(http://keystore-explorer.sourceforge.net/)这样做了。使用“检查证书”选项,打开从Godaddy收到的PEM文件(1b27b7d7a29a06.pem)点击你的证书(不是一个)其他来自GoDaddy),点击“PEM”,点击“导出”。我将此证书命名为1b27b7d7a29a06-mycert.pem。

Download the root (gdroot-g2.crt) and intermediate (gdig2.crt) certificates from GoDaddy (https://certs.godaddy.com/anonymous/repository.pki)

从GoDaddy(https://certs.godaddy.com/anonymous/repository.pki)下载root(gdroot-g2.crt)和中间(gdig2.crt)证书

Note that these are/one must use the GoDaddy G2 root and intermediate certificates.

请注意,这些是/必须使用GoDaddy G2根和中间证书。

Next install these certificates in this order:

接下来按此顺序安装这些证书:

keytool -v -importcert -trustcacerts -keystore myKeystore -storepass abc123 -file gdroot-g2.crt -alias gdroot-g2

keytool -v -importcert -trustcacerts -keystore myKeystore -storepass abc123 -file gdroot-g2.crt -alias gdroot-g2

keytool -v -importcert -trustcacerts -keystore myKeystore -storepass abc123 -file gdig2.crt -alias gdig2

keytool -v -importcert -trustcacerts -keystore myKeystore -storepass abc123 -file gdig2.crt -alias gdig2

keytool -v -importcert -keystore myKeystore -storepass abc123 -alias myKey -file 1b27b7d7a29a06-mycert.pem

keytool -v -importcert -keystore myKeystore -storepass abc123 -alias myKey -file 1b27b7d7a29a06-mycert.pem

now you can sign your app:

现在你可以签署你的应用程序:

jarsigner -keystore myKeystore -storepass abc123 -sigalg SHA1withRSA -digestalg SHA-1 time.jar mykey

jarsigner -keystore myKeystore -storepass abc123 -sigalg SHA1withRSA -digestalg SHA-1 time.jar mykey

#8


0  

I had the certificate error (CA not trusted) using the Chrome/FF java plugin to deploy an application from my webserver (so not a java applet). Problem was solved for me when adding other Godaddy (intermediate) CA certs to my web server. I created a ticket with godaddy and they responded (quite rapidly)

我使用Chrome / FF java插件从我的网络服务器部署应用程序(因此不是Java小程序)时出现了证书错误(CA不信任)。在我的Web服务器中添加其他Godaddy(中间)CA证书时,问题解决了。我和godaddy创建了一张票,然后他们回复了(很快)

Dear Sir or Madam,

亲爱的先生或女士,

Thank you for contacting secure certificate support. You will need to use the intermediate certificate bundle with the cross certificate and the G1 root certificate. This will resolve this issue. You can obtain the certificates listed below at https://certs.godaddy.com/repository.

感谢您联系安全证书支持。您需要将中间证书包与交叉证书和G1根证书一起使用。这将解决此问题。您可以通过https://certs.godaddy.com/repository获取下面列出的证书。

Intermediate certificate bundle - gdig2_bundle.crt Root certificate - gd-class2-root.crt

中间证书包 - gdig2_bundle.crt根证书 - gd-class2-root.crt

#9


0  

importing the GoDaddy bundle solves the problem:

导入GoDaddy包解决了问题:

export JAVA_HOME=/usr/lib/jvm/java-8-oracle/
wget https://certs.godaddy.com/repository/gd_bundle-g2.crt
$JAVA_HOME/bin/keytool -import -alias root -file ./gd_bundle-g2.crt -storepass changeit -trustcacerts -keystore $JAVA_HOME/jre/lib/security/cacerts

#10


-1  

I have to say,

我不得不说,

this whole Java signing bs seems to be a singular method for Java not to die off in favor of better code options.

这整个Java签名bs似乎是Java的一种独特方法,不会因为更好的代码选项而死亡。

In reality I think it is killing java. I would rather use any other method of coding (php/flash/etc) then ever use Java again. Way to go Oracle!

实际上我认为这是杀死java。我宁愿使用任何其他编码方法(php / flash / etc)然后再次使用Java。去甲骨文的方法!

#1


10  

The workaround is to contact GoDaddy and have them reissue your organization's certificate. During the certificate setup process, you must select a SHA-1 codesign certificate instead of SHA-2. The option to select SHA-1 will only be available if you certificate validity does not extend to 2016 (see below), so make sure they understand your end goal is to recreate your SHA-2 certificate as SHA-1, so they know to sell you a cert with the correct validity period.

解决方法是联系GoDaddy并让他们重新颁发您组织的证书。在证书设置过程中,您必须选择SHA-1协同代码证书而不是SHA-2。选择SHA-1的选项仅在证书有效期未延伸至2016(见下文)时才可用,因此请确保他们了解您的最终目标是将SHA-2证书重新创建为SHA-1,因此他们知道向您出售具有正确有效期的证书。

I traded my SHA-2 cert for a SHA-1 today, and GoDaddy's Java Code Signing instructions worked perfectly.

我今天将SHA-2证书交换为SHA-1,GoDaddy的Java代码签名说明完美无缺。

GoDaddy informed me Keytool may have trouble importing a certificate response chain generated from their SHA-2 (2048 length) codesign certificate. I withhold judgment of Keytool since it imports SHA-2 certs fine when the GoDaddy's root SHA1 cert is lopped from the pem file per @mogsie's answer.

GoDaddy告诉我,Keytool可能无法导入从其SHA-2(2048长度)协同代码证书生成的证书响应链。我保留对Keytool的判断,因为当根据@mogsie的答案从gom文件中删除GoDaddy的根SHA1证书时,它会导入SHA-2证书。

GoDaddy goes with SHA-2 automatically when it grants codesign certificates that will extend into 2017 because Microsoft will not accept less than SHA-2 beginning January 1, 2016, so if you're in the market for a SHA-1 certificate, it will have short-term validity.

GoDaddy在授予将延长到2017年的代码签名证书时会自动使用SHA-2,因为从2016年1月1日开始微软不会接受少于SHA-2,因此如果您在市场上获得SHA-1证书,它将会具有短期效力。

The issue might go away with a Java Keytool update (I was working with 1.6), or if GoDaddy's Sha256withRSA self-signed certificate becomes widely trusted.

Java Keytool更新(我使用1.6)或GoDaddy的Sha256withRSA自签名证书变得广泛受信任,这个问题可能会消失。

#2


5  

The answer, as mentioned by Waterbear, is to have your GoDaddy cert reissued or rekeyed by GoDaddy using SHA-1. The reason is that GoDaddy has two CA servers: Class 2 CA which is used for signing SHA-1 certificates, and G2 CA which is used for signing SHA-2 certificates. While the older Class 2 CA is trusted by the Java Truststore (and thus SHA-1 certificates are trusted), the newer G2 CA is not, so its SHA-2certificates are not trusted unless you manually install its root certificate (which defeats the purpose of buying a cert in the first place). Hopefully GoDaddy's G2 CA becomes trusted by the Java Truststore soon (Before 2016!), but until that happens a GoDaddy SHA-2 cert is no better than a self-signed cert.

正如Waterbear所提到的,答案是让GoDaddy使用SHA-1重新发布或重新设置你的GoDaddy证书。原因是GoDaddy有两个CA服务器:用于签署SHA-1证书的Class 2 CA和用于签署SHA-2证书的G2 CA.虽然旧的Class 2 CA受Java Truststore信任(因此SHA-1证书是受信任的),但较新的G2 CA不受信任,因此除非您手动安装其根证书(这违背了目的),否则其SHA-2证书不受信任首先购买证书)。希望GoDaddy的G2 CA很快就会受到Java Truststore的信任(2016年之前!),但在此之前,GoDaddy SHA-2证书并不比自签名证书更好。

#3


5  

Since I enjoyed (not) the process of creating a codesinging certificate so much, I thought I would share the process I went thru, and hopefully when you need to generate your own, this will save you some of the heartache and pain .

由于我非常喜欢(不)创建代码验证证书的过程,我想我会分享我通过的过程,并希望当你需要生成自己的过程时,这将为你节省一些心痛和痛苦。

I used godaddy , but I have to believe whoever the CA is the steps should be very similar.

我使用的是godaddy,但我必须相信CA的步骤应该非常相似。

These are the steps I went thru:

这些是我通过的步骤:

(note that godaddy does not create a codesigning certificate in jks format and there is an extra step involved to convert the keystore to jks)

(请注意,godaddy不会以jks格式创建代码签名证书,并且还需要额外的步骤将密钥库转换为jks)

Create keystore:

keytool -genkey -alias codesigncert -keypass yourpassword -keyalg RSA - keysize 2048 -dname "cn=server1.lccc.edu, OU=College Name , O=College Name , L=Schnecksville, ST=Pennsylvania,C=US" - keystore /home/oracle/codesignstore/codesignstore -storepass yourpassword -validity 720 (storepass and keypass can be the same)

keytool -genkey -alias codesigncert -keypass yourpassword -keyalg RSA - keysize 2048 -dname“cn = server1.lccc.edu,OU = College Name,O = College Name,L = Schnecksville,ST = Pennsylvania,C = US” - keystore / home / oracle / codesignstore / codesignstore -storepass yourpassword -validity 720(storepass和keypass可以是相同的)

Generater crt for godaddy

keytool -certreq -v -alias codesigncert - file /home/oracle/codesignstore/codesignstore.pem - keystore /home/oracle/codesignstore/codesignstore

keytool -certreq -v -alias codesigncert - file /home/oracle/codesignstore/codesignstore.pem - keystore / home / oracle / codesignstore / codesignstore

using an editor open codesignstore.pem and paste it into the godaddy site

when godaddy verifies the account and you pay your money the 'pending' status will go away

当godaddy验证帐户并且您付款时,“待处理”状态将消失

go to your godaddy account (https://mya.godaddy.com/)

去你的godaddy帐户(https://mya.godaddy.com/)

click on myaccount at the top of the page (in the black header)

点击页面顶部的myaccount(在黑色标题中)

click on manage SSL Certificates

单击“管理SSL证书”

select the codesigning certificate listed

选择列出的代码签名证书

click on the Launch button

单击“启动”按钮

download the file as a PEM file

将文件下载为PEM文件

save it on your local pc

将它保存在您的本地电脑上

open firefox, in the advanced section select view certificates, and the

certificate should be listed on the managed views.

证书应列在托管视图上。

highlight the certificate and select backup (export) and save it as a pkcs12 file

突出显示证书并选择备份(导出)并将其另存为pkcs12文件

click on view certificates at the top of the screen next to certificate viewer is the alias in double quotes, right this down it will be the alias to be used on the jarsigner command below

单击证书查看器旁边的屏幕顶部的视图证书是双引号中的别名,右下角它将是下面的jarsigner命令中使用的别名

copy the file to the server where the codesigning certificate is going to be

used: (e.g server1 /home/oracle/code_sign_cert_from_godaddy/ godaddy_pkcs12.p12) * this is the new keystore

used :(例如server1 / home / oracle / code_sign_cert_from_godaddy / godaddy_pkcs12.p12)*这是新的密钥库

since the keystore has to be of the type jks, and godaddy does't create a jks file it has to be converted to jks format

因为密钥库必须是jks类型,而且godaddy不会创建jks文件,所以必须将其转换为jks格式

convert pcks12 to jks

keytool -importkeystore - srckeystore /home/oracle/code_sign_cert_from_godaddy/godaddy_pkcs12. p12 -srcstoretype pkcs12 - destkeystore /home/oracle/code_sign_cert_from_godaddy/godaddy_jks.jks -deststoretype jks

keytool -importkeystore - srckeystore / home / oracle / code_sign_cert_from_godaddy / godaddy_pkcs12。 p12 -srcstoretype pkcs12 - destkeystore /home/oracle/code_sign_cert_from_godaddy/godaddy_jks.jks-deststoretype jks

jar file processing:

unsign jacob.jar... i copied the jacob.jar file to a test directory /test_jacob and renamed it jacob1.jar (note 760815.1)

unsign jacob.jar ...我将jacob.jar文件复制到测试目录/ test_jacob并将其重命名为jacob1.jar(注760815.1)

jar xf jacob1.jar

jar xf jacob1.jar

extracts into "com" and "META-INF" folders, remove the "META-INF" folder

提取到“com”和“META-INF”文件夹,删除“META-INF”文件夹

remove the old jacob1.jar

删除旧的jacob1.jar

recreate the jacob1.jar from the /test_jacob directory

从/ test_jacob目录重新创建jacob1.jar

jar -cvf jacob1.jar *

jar -cvf jacob1.jar *

run jarsigner -verify jacob1.jar, should show unisigned.

运行jarsigner -verify jacob1.jar,应该显示unisigned。

create a text file call mymanifest.txt

创建一个文本文件,调用mymanifest.txt

  Permissions: all-permissions

  Codebase: *

  Application-Name: OracleForms

jar -ufm jacob1.jar mymanifest.txt (this puts the new manifest info into the jar file)..

jar -ufm jacob1.jar mymanifest.txt(这会将新的清单信息放入jar文件中)

you can open jacob1.jar with the unzip jacob1.jar -d directory where unzip will reside to verify that the mymanifest.txt file is now part of the jar file.

你可以使用unzip jacob1.jar -d目录打开jacob1.jar,其中unzip将驻留在该目录中以验证mymanifest.txt文件现在是jar文件的一部分。

sign jar file

jarsigner - keystore /home/oracle/code_sign_cert_from_godaddy/godaddy_jks.jks - storepass yourpassword - signedjar /home/oracle/Oracle/Middleware/Oracle_FRHome1/forms/java/tes t_jacob/Signedjacob1.jar jacob1.jar "lehigh carbon community college's godaddy.com, inc. id" (this alias came from the firefox process above)

jarsigner - keystore /home/oracle/code_sign_cert_from_godaddy/godaddy_jks.jks - storepass yourpassword - signedjar / home / oracle / Oracle / Middleware / Oracle_FRHome1 / forms / java / tes t_jacob / Signedjacob1.jar jacob1.jar“lehigh carbon community college's godaddy.com ,inc.id“(这个别名来自上面的firefox进程)

the -signedjar file option was required, without it I was getting errors

note the alias is always the last entry on the jarsigner command and

there is no –alias option as there was on the keytool command

keytool命令没有-alias选项

verify jar file is signed

jarsigner -verify Signedjacob1.jar will display:

jarsigner -verify Signedjacob1.jar将显示:

jar verified.

jar验证。

show whats in the jar file

jar -tvf Signedjacob1.jar

jar -tvf Signedjacob1.jar

the .SF file is insided the .jar file, the .DSA file is replaced by the .RSA

file which is also inside the .jar file

文件也在.jar文件中

from the output of the jar -tvf Signedjacob1.jar

2721 Mon May 05 15:57:08 EDT 2014 META-INF/LEHIGH_C.SF

2721 Mon May 05 15:57:08 EDT 2014 META-INF / LEHIGH_C.SF

4231 Mon May 05 15:57:08 EDT 2014 META-INF/LEHIGH_C.RSA

4231 Mon May 05 15:57:08 EDT 2014 META-INF / LEHIGH_C.RSA

I copied the Signedjacob1.jar file to the $ORACLE_HOME/forms/java directory and then using the

我将Signedjacob1.jar文件复制到$ ORACLE_HOME / forms / java目录,然后使用

login to the weblogic enterprise manager

登录weblogic企业管理器

I changed the webutilarchive parameter from Jacob.jar to Signedjacob1.jar for each instance

我为每个实例将webutilarchive参数从Jacob.jar更改为Signedjacob1.jar

( em >>forms>>web configuration >> instance name >> all (the first entry should be the archive parameter)

(em >> forms >> web配置>>实例名>> all(第一个条目应该是archive参数)

When changing the jacob.jar to the Signedjacob1.jar , I did it for each of my test instances before I did it for production, just in case.

将jacob.jar更改为Signedjacob1.jar时,我为每个测试实例执行了此操作,然后再进行生产,以防万一。

Stop and start wls_forms and you should be good to go..

停下来开始wls_forms,你应该好好去......

#4


2  

@Waterbear Thanks so much for your solution about getting an SHA-1 certificate instead of SHA-2. This was definitely the problem I was having. (I would have posted this underneath your comment, but * said it was way too long.) I had gotten a 3-year certificate, and by default GoDaddy gives an SHA-2 for certificates expiring after a certain date. However, even when I re-keyed and asked for an SHA-1, I still ended up with an SHA-2. I had to revoke my certificate and then start the process from scratch to get an SHA-1 certificate. (By starting from scratch, I mean GoDaddy must again verify your company and phone number and all that.) By the way, if you do revoke your certificate, make sure you ask GoDaddy for permission first because technically they don't have to give you a refund. In addition, I wasn't able to get a 3-year certificate because anything that expires after a certain date (2016?) must be SHA-2 and not SHA-1. I basically had to get a refund for my 3-year certificate and instead get a 1-year certificate to even have the SHA-1 option. But after going with SHA-1, GoDaddy's instructions in approach#1 worked fine. I would recommend doing generating your CSR manually using the keytool command (instead of automatically through a web browser). Later, you just download the PEM file and import it into the keystore using the keytool command. (This is what GoDaddy's describes in "approach 1" in the link posted in the question.)

@Waterbear非常感谢您获得SHA-1证书而不是SHA-2的解决方案。这绝对是我遇到的问题。 (我会在你的评论下面发布这个,但是*表示它太长了。)我已经获得了3年的证书,默认情况下,GoDaddy会在特定日期之后颁发SHA-2证书。但是,即使我重新键入并要求使用SHA-1,我仍然使用SHA-2。我不得不撤销我的证书,然后从头开始获取SHA-1证书。 (从头开始,我的意思是GoDaddy必须再次验证您的公司和电话号码以及所有这些。)顺便说一句,如果您撤销证书,请确保先向GoDaddy申请许可,因为从技术上讲,他们不必给予你退款了。另外,我无法获得3年证书,因为在特定日期(2016年?)之后到期的任何内容必须是SHA-2而不是SHA-1。我基本上不得不获得3年期证书的退款,而是获得1年的证书甚至可以获得SHA-1选项。但是在使用SHA-1之后,GoDaddy在方法#1中的指示运行良好。我建议使用keytool命令手动生成CSR(而不是通过Web浏览器自动生成)。稍后,您只需下载PEM文件并使用keytool命令将其导入密钥库。 (这是GoDaddy在问题中发布的链接中的“方法1”中描述的内容。)

Lastly if you do have to have a certificate reissued, and go through this process again, I would highly recommend choosing another company besides GoDaddy for code-signing. Their tech support was absolutely horrendous. Their support techs even admitted to me they weren't trained in this. The hours spent on this issue greatly offset any money saved on the cert.

最后,如果您必须重新签发证书并再次执行此过程,我强烈建议您选择除GoDaddy之外的其他公司进行代码签名。他们的技术支持绝对是可怕的。他们的支持技术人员甚至向我承认他们没有接受过这方面的培训。在这个问题上花费的时间大大抵消了证书上节省的任何资金。

#5


1  

keytool -import -trustcacerts -keystore codesignstore -storepass <yourstorepwd> -alias codesigncert -file mycert.cer

First thing, you ** MUST HAVE ** the mycert.cer file. Otherwise, you do not have the ability to import the cert.

首先,你必须** mycert.cer文件。否则,您无法导入证书。

Get a "lay of the land" - What is in the current keystore file? We want to list (or show) what is in the keystore..

得到一块“土地” - 当前的密钥库文件是什么?我们想列出(或显示)密钥库中的内容..

keytool -list -v -keystore codesignstore

If it prompts you for the password, you can just press the ENTER key and it will bark about it not being trusted, but for expediency, it is fine.

如果它提示你输入密码,你可以按下ENTER键,它会咆哮它不被信任,但为了方便,它没关系。

If you want to "pump" the results into a text file..

如果要将结果“泵”到文本文件中..

echo.|keytool -list -v -keystore codesignstore > kstore_result.txt

Note: the echo. does like what I previously mentioned about "pressing ENTER" so don't become too attached to that. :)

注意:回声。就像我之前提到的关于“按ENTER”的那样,所以不要过于依赖它。 :)

keytool -genkey -alias codesigncert -keyalg RSA -validity 1825 -keysize 2048 -keypass <yourstorepwd> -keystore codesignstore -storepass <yourstorepwd>

Other options:

其他选择:

-genkey = generate a key
-keyalg RSA = use RSA's key alogorithm
-validity 1825 = how long is the key good for?  Primarily used with self-signed certs as the certs from verisign or Thawte have their own expiration
-keysize 2048 = Is this a 1024 or 2048-bit enryption?
-keypass <yourstorepwd>
-keystore codesignstore
-storepass <yourstorepwd>

Thing you have to be very careful of here and Support will not tell you about this.. If you try to import other certs alongside the existing ones, you need to be careful you don't botch the whole thing. :)

你必须非常小心这里,支持不会告诉你这个..如果你试图导入其他证书与现有的证书,你需要小心你不要把整个事情搞得一团糟。 :)

If you do have a problem of course, you can delete the alias and import again..

如果您确实遇到问题,可以删除别名并再次导入..

keytool -delete -alias codesigncert -storepass <yourstorepwd> -keystore codesignstore

One of the things that I like to do is to "stack" the command to be sure that I work down through the list.

我喜欢做的一件事就是“堆叠”命令以确保我在列表中工作。

For example, you have from Godaddy:

例如,你来自Godaddy:

keytool -import -trustcacerts -keystore codesignstore -storepass <yourstorepwd> -alias codesigncert -file mycert.cer

Then, I take each command and set it up like the following to "walk" down the list:

然后,我接受每个命令并将其设置为如下所示“向下”列表:

keytool
-import
-trustcacerts
-keystore codesignstore
-storepass <yourstorepwd>
-alias codesigncert
-file mycert.cer

Then, looking at this list, does my version of keytool support each of these? You have -import as the first..

那么,看看这个列表,我的keytool版本是否支持这些?你有 - 作为第一个进口..

I just ran keytool -help and I don't see: -import, but do see -importcert

我刚刚运行了keytool -help,我没有看到:-import,但确实看到了-importcert

There maybe an issue there?

那里可能有问题吗?

Oracle shows us.. http://docs.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html

Oracle向我们展示了.. http://docs.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html

So, you may have to make some adjustments..

所以,你可能需要做一些调整..

Here is one that I setup on on of our local Apache Tomcat servers (Windows):

这是我在本地Apache Tomcat服务器(Windows)上设置的一个:

%JAVA_HOME%\bin\keytool -delete -alias tomcat -storepass somepass -keystore %JAVA_HOME%\bin\.keystore

And then..

接着..

%JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA -validity 1825 -keysize 2048 -keypass somepass -keystore %JAVA_HOME%\bin\.keystore -storepass somepass
What is your first and last name?
  [Unknown]:  secure.someserver.com
What is the name of your organizational unit?
  [Unknown]:  COMPANY
What is the name of your organization?
  [Unknown]:  COMPANY
What is the name of your City or Locality?
  [Unknown]:  ANYTOWN
What is the name of your State or Province?
  [Unknown]:  MI
What is the two-letter country code for this unit?
  [Unknown]:  US
Is CN=secure.someserver.com, OU=COMPANY, O=COMPANY, L=ANYTOWN, ST=MI, C=US correct?
  [no]:  yes

Note: When you run this, you will not see if it is successful or not.

注意:运行此操作时,您将看不到它是否成功。

Let's start here and see what the results are..

让我们从这里开始看看结果如何......

#6


1  

I found that of the four certificates you get from the godaddy PEM download, the first one is the self-signed root certificate.

我发现你从godaddy PEM下载获得的四个证书中,第一个是自签名的根证书。

To see the chain (on unix):

要查看链(在unix上):

keytool -printcert -file response-from-godaddy.pem | grep -C1 ^Owner

The response shows the four certificates that make up the chain, all the way to the root.

响应显示构成链的四个证书,一直到根。

Certificate[1]:
Owner: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
Issuer: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
--
Certificate[2]:
Owner: CN=Go Daddy Root Certificate Authority - G2, OU=https://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
Issuer: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
--
Certificate[3]:
Owner: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
Issuer: CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
--
Certificate[4]:
Owner: CN=REDACTED
Issuer: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US

Apparently the first one is already in the Java standard cacerts as the trusted root certificate. The fact that it is in the .pem file trips keytool up.

显然,第一个已经在Java标准cacerts中作为受信任的根证书。它在.pem文件中的事实使keytool跳起来。

I struggled with the same problem rekeying a few times, and I got lucky:

我为同样的问题挣扎了好几次,我很幸运:

  • Open up the PEM file.
  • 打开PEM文件。
  • Delete the first block of ----BEGIN to ----END,
  • 删除---- BEGIN的第一个块到---- END,
  • Run your keytool -import on the file containing the remaining three certificates.
  • 在包含其余三个证书的文件上运行keytool -import。

Presto!

普雷斯托!

keytool -importcert -v -trustcacerts -keystore XXX -alias codesigning -file 234.pem

Result:

结果:

Certificate reply was installed in keystore
[Storing XXX]

#7


0  

Here's what I did..

这就是我做的......

keytool -v -genkey -dname "CN=XXX, OU=YYY, O=ZZZ, L=CCC, ST=SSS, C=US" -alias myKey -keypass abc123 -keystore myKeystore -storepass abc123 -validity 1096 -keyalg RSA -keysize 2048 -sigalg SHA1withRSA

keytool -v -genkey -dname“CN = XXX,OU = YYY,O = ZZZ,L = CCC,ST = SSS,C = US”-alias myKey -keypass abc123 -keystore myKeystore -storepass abc123 -validity 1096 -keyalg RSA -keysize 2048 -sigalg SHA1withRSA

keytool -certreq -keyalg RSA -keysize 2048 -sigalg SHA1withRSA -v -alias myKey -file mycsr.pem -keystore myKeystore -storepass abc123

keytool -certreq -keyalg RSA -keysize 2048 -sigalg SHA1withRSA -v -alias myKey -file mycsr.pem -keystore myKeystore -storepass abc123

Submit request (mycsr.pem) to GoDaddy, download PEM file (1b27b7d7a29a06.pem in this case).

将请求(mycsr.pem)提交给GoDaddy,下载PEM文件(本例中为1b27b7d7a29a06.pem)。

The downloaded PEM file contains my signed certificate along with others in the certificate chain. I found keytool would not accept the PEM file as downloaded. I had to remove my certificate from downloaded certificate. I did this via Key Store Explorer (http://keystore-explorer.sourceforge.net/) Use the "Examine a Certificate" option, open the PEM file received from Godaddy (1b27b7d7a29a06.pem) click on the your certificate (not one of the others from GoDaddy), click on "PEM", click on "Export". I named this certificate 1b27b7d7a29a06-mycert.pem.

下载的PEM文件包含我签名的证书以及证书链中的其他证书。我发现keytool不会接受下载的PEM文件。我不得不从下载的证书中删除我的证书。我通过Key Store Explorer(http://keystore-explorer.sourceforge.net/)这样做了。使用“检查证书”选项,打开从Godaddy收到的PEM文件(1b27b7d7a29a06.pem)点击你的证书(不是一个)其他来自GoDaddy),点击“PEM”,点击“导出”。我将此证书命名为1b27b7d7a29a06-mycert.pem。

Download the root (gdroot-g2.crt) and intermediate (gdig2.crt) certificates from GoDaddy (https://certs.godaddy.com/anonymous/repository.pki)

从GoDaddy(https://certs.godaddy.com/anonymous/repository.pki)下载root(gdroot-g2.crt)和中间(gdig2.crt)证书

Note that these are/one must use the GoDaddy G2 root and intermediate certificates.

请注意,这些是/必须使用GoDaddy G2根和中间证书。

Next install these certificates in this order:

接下来按此顺序安装这些证书:

keytool -v -importcert -trustcacerts -keystore myKeystore -storepass abc123 -file gdroot-g2.crt -alias gdroot-g2

keytool -v -importcert -trustcacerts -keystore myKeystore -storepass abc123 -file gdroot-g2.crt -alias gdroot-g2

keytool -v -importcert -trustcacerts -keystore myKeystore -storepass abc123 -file gdig2.crt -alias gdig2

keytool -v -importcert -trustcacerts -keystore myKeystore -storepass abc123 -file gdig2.crt -alias gdig2

keytool -v -importcert -keystore myKeystore -storepass abc123 -alias myKey -file 1b27b7d7a29a06-mycert.pem

keytool -v -importcert -keystore myKeystore -storepass abc123 -alias myKey -file 1b27b7d7a29a06-mycert.pem

now you can sign your app:

现在你可以签署你的应用程序:

jarsigner -keystore myKeystore -storepass abc123 -sigalg SHA1withRSA -digestalg SHA-1 time.jar mykey

jarsigner -keystore myKeystore -storepass abc123 -sigalg SHA1withRSA -digestalg SHA-1 time.jar mykey

#8


0  

I had the certificate error (CA not trusted) using the Chrome/FF java plugin to deploy an application from my webserver (so not a java applet). Problem was solved for me when adding other Godaddy (intermediate) CA certs to my web server. I created a ticket with godaddy and they responded (quite rapidly)

我使用Chrome / FF java插件从我的网络服务器部署应用程序(因此不是Java小程序)时出现了证书错误(CA不信任)。在我的Web服务器中添加其他Godaddy(中间)CA证书时,问题解决了。我和godaddy创建了一张票,然后他们回复了(很快)

Dear Sir or Madam,

亲爱的先生或女士,

Thank you for contacting secure certificate support. You will need to use the intermediate certificate bundle with the cross certificate and the G1 root certificate. This will resolve this issue. You can obtain the certificates listed below at https://certs.godaddy.com/repository.

感谢您联系安全证书支持。您需要将中间证书包与交叉证书和G1根证书一起使用。这将解决此问题。您可以通过https://certs.godaddy.com/repository获取下面列出的证书。

Intermediate certificate bundle - gdig2_bundle.crt Root certificate - gd-class2-root.crt

中间证书包 - gdig2_bundle.crt根证书 - gd-class2-root.crt

#9


0  

importing the GoDaddy bundle solves the problem:

导入GoDaddy包解决了问题:

export JAVA_HOME=/usr/lib/jvm/java-8-oracle/
wget https://certs.godaddy.com/repository/gd_bundle-g2.crt
$JAVA_HOME/bin/keytool -import -alias root -file ./gd_bundle-g2.crt -storepass changeit -trustcacerts -keystore $JAVA_HOME/jre/lib/security/cacerts

#10


-1  

I have to say,

我不得不说,

this whole Java signing bs seems to be a singular method for Java not to die off in favor of better code options.

这整个Java签名bs似乎是Java的一种独特方法,不会因为更好的代码选项而死亡。

In reality I think it is killing java. I would rather use any other method of coding (php/flash/etc) then ever use Java again. Way to go Oracle!

实际上我认为这是杀死java。我宁愿使用任何其他编码方法(php / flash / etc)然后再次使用Java。去甲骨文的方法!